Bug 208754 - kernel - recursive locking in dm_request (md->io_lock)
Summary: kernel - recursive locking in dm_request (md->io_lock)
Keywords:
Status: CLOSED DUPLICATE of bug 204311
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-10-01 17:22 UTC by Michal Jaegermann
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-10-04 23:28:10 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Michal Jaegermann 2006-10-01 17:22:59 UTC
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.

Comment 1 Michal Jaegermann 2006-10-01 18:24:48 UTC
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 23:28:10 UTC

*** 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.