Bug 208754
| Summary: | kernel - recursive locking in dm_request (md->io_lock) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | CLOSED DUPLICATE | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | wtogami |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-10-04 23:28:10 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Actually a missing partition is not the reason. I have now SCSI device sdc: drive cache: write back sdc: sdc1 and still the same "possible recursive locking detected" with the same traceback. /dev/sdb has a dmraid signature on it, even if no dmraid is really in use, but a similar signature on /dev/sdc was removed and initrd rebuild after that. Still the same as above. |
Description of problem: I got the following - SCSI device sdc: drive cache: write back sdc: unknown partition table sd 3:0:0:0: Attached scsi disk sdc device-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialised: dm-devel ============================================= [ INFO: possible recursive locking detected ] 2.6.18-1.2708.fc6 #1 --------------------------------------------- init/1 is trying to acquire lock: (&md->io_lock){----}, at: [<ffffffff880fa654>] dm_request+0x25/0x130 [dm_mod] but task is already holding lock: (&md->io_lock){----}, at: [<ffffffff880fa654>] dm_request+0x25/0x130 [dm_mod] other info that might help us debug this: 1 lock held by init/1: #0: (&md->io_lock){----}, at: [<ffffffff880fa654>] dm_request+0x25/0x130 [dm_mod] stack backtrace: Call Trace: [<ffffffff8026ed0d>] show_trace+0xae/0x336 [<ffffffff8026efaa>] dump_stack+0x15/0x17 [<ffffffff802a8821>] __lock_acquire+0x135/0x9d9 [<ffffffff802a9668>] lock_acquire+0x4b/0x69 [<ffffffff802a5f1d>] down_read+0x3e/0x4a [<ffffffff880fa654>] :dm_mod:dm_request+0x25/0x130 [<ffffffff8021cf44>] generic_make_request+0x21a/0x235 [<ffffffff880f9402>] :dm_mod:__map_bio+0xca/0x104 [<ffffffff880f9e48>] :dm_mod:__split_bio+0x16a/0x36b [<ffffffff880fa74c>] :dm_mod:dm_request+0x11d/0x130 [<ffffffff8021cf44>] generic_make_request+0x21a/0x235 [<ffffffff80235fc1>] submit_bio+0xd3/0xdc [<ffffffff8021b366>] submit_bh+0x100/0x124 [<ffffffff802e271b>] block_read_full_page+0x283/0x2a1 [<ffffffff802e4dc2>] blkdev_readpage+0x13/0x15 [<ffffffff80213576>] __do_page_cache_readahead+0x17b/0x1fc [<ffffffff80234f3a>] blockable_page_cache_readahead+0x5f/0xc1 [<ffffffff8021476f>] page_cache_readahead+0x146/0x1bb [<ffffffff8020c2ba>] do_generic_mapping_read+0x157/0x4b4 [<ffffffff8020c775>] __generic_file_aio_read+0x15e/0x1b4 [<ffffffff802c90be>] generic_file_read+0xc6/0xe0 [<ffffffff8020b615>] vfs_read+0xcc/0x172 [<ffffffff80212197>] sys_read+0x47/0x6f [<ffffffff8026094e>] system_call+0x7e/0x83 DWARF2 unwinder stuck at system_call+0x7e/0x83 Leftover inexact backtrace: A partition table is indeed "unknown" as an initial part of that disk was just wiped out in order to remove traces of whatever could be present there (and possibly an old RAID signature or whatever can be mistaken for it). Version-Release number of selected component (if applicable): kernel 2.6.18-1.2708.fc6 How reproducible: So far it looks pretty consistent with a disk treated as mentioned above.