Bug 208754 - kernel - recursive locking in dm_request (md->io_lock)
kernel - recursive locking in dm_request (md->io_lock)
Status: CLOSED DUPLICATE of bug 204311
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-01 13:22 EDT by Michal Jaegermann
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-04 19:28:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2006-10-01 13:22:59 EDT
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@redhat.com

=============================================
[ 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.
Comment 1 Michal Jaegermann 2006-10-01 14:24:48 EDT
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.
Comment 2 Dave Jones 2006-10-04 19:28:10 EDT

*** This bug has been marked as a duplicate of 204311 ***

Note You need to log in before you can comment on or make changes to this bug.