Bug 208754 - kernel - recursive locking in dm_request (md->io_lock)
Summary: kernel - recursive locking in dm_request (md->io_lock)
Status: CLOSED DUPLICATE of bug 204311
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
Depends On:
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:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-04 23:28:10 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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@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

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

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