Bug 208732 - circular dependency reported by md (bdev_part_lock_key / reconfig_mutex)
Summary: circular dependency reported by md (bdev_part_lock_key / reconfig_mutex)
Keywords:
Status: CLOSED CURRENTRELEASE
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:
: 208829 208840 (view as bug list)
Depends On:
Blocks: FCMETA_LOCKDEP
TreeView+ depends on / blocked
 
Reported: 2006-10-01 03:49 UTC by Kostas Georgiou
Modified: 2007-11-30 22:11 UTC (History)
4 users (show)

Fixed In Version: fc6
Clone Of:
Environment:
Last Closed: 2006-10-31 09:33:36 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Kostas Georgiou 2006-10-01 03:49:36 UTC
Description of problem:

....
md: bind<sda2>

=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.18-1.2708.fc6 #1
-------------------------------------------------------
init/1 is trying to acquire lock:
 (&bdev_part_lock_key){--..}, at: [<ffffffff802667ef>] mutex_lock+0x2a/0x2e

but task is already holding lock:
 (&new->reconfig_mutex){--..}, at: [<ffffffff80266425>]
mutex_lock_interruptible+0x2a/0x2e

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #2 (&new->reconfig_mutex){--..}:
       [<ffffffff802a9667>] lock_acquire+0x4a/0x69
       [<ffffffff8026621f>] __mutex_lock_interruptible_slowpath+0xe4/0x2c0
       [<ffffffff80266424>] mutex_lock_interruptible+0x29/0x2e
       [<ffffffff80417534>] md_open+0x2e/0x69
       [<ffffffff802e54cd>] do_open+0xa3/0x343
       [<ffffffff802e5a0d>] blkdev_open+0x29/0x5c
       [<ffffffff8021f725>] __dentry_open+0xe8/0x1f5
       [<ffffffff80227051>] nameidata_to_filp+0x2c/0x3e
       [<ffffffff8022914a>] do_filp_open+0x35/0x46
       [<ffffffff8021a835>] do_sys_open+0x4e/0xcd
       [<ffffffff80233d86>] sys_open+0x1a/0x1d
       [<ffffffff8026094d>] system_call+0x7d/0x83

-> #1 (&bdev->bd_mutex){--..}:
       [<ffffffff802a9667>] lock_acquire+0x4a/0x69
       [<ffffffff80266648>] __mutex_lock_slowpath+0xe4/0x261
       [<ffffffff802667ee>] mutex_lock+0x29/0x2e
       [<ffffffff802e549a>] do_open+0x70/0x343
       [<ffffffff802e5883>] blkdev_get+0x73/0x86
       [<ffffffff802e5552>] do_open+0x128/0x343
       [<ffffffff802e5883>] blkdev_get+0x73/0x86
       [<ffffffff802e5b0f>] open_by_devnum+0x36/0x46
       [<ffffffff8041181c>] md_import_device+0x240/0x267
       [<ffffffff80416189>] md_ioctl+0xb4/0x1431
       [<ffffffff80348348>] blkdev_driver_ioctl+0x62/0x78
       [<ffffffff803489b9>] blkdev_ioctl+0x65b/0x6b7
       [<ffffffff802e4d49>] block_ioctl+0x1a/0x1f
       [<ffffffff80243db3>] do_ioctl+0x29/0x77
       [<ffffffff802326ff>] vfs_ioctl+0x259/0x277
       [<ffffffff8024ed14>] sys_ioctl+0x5e/0x82
       [<ffffffff8026094d>] system_call+0x7d/0x83

-> #0 (&bdev_part_lock_key){--..}:
       [<ffffffff802a9667>] lock_acquire+0x4a/0x69
       [<ffffffff80266648>] __mutex_lock_slowpath+0xe4/0x261
       [<ffffffff802667ee>] mutex_lock+0x29/0x2e
       [<ffffffff802e5138>] bd_claim_by_disk+0x73/0x1c2
       [<ffffffff80411a55>] bind_rdev_to_array+0x212/0x23a
       [<ffffffff80413817>] autorun_devices+0x219/0x316
       [<ffffffff804161e8>] md_ioctl+0x113/0x1431
       [<ffffffff80348348>] blkdev_driver_ioctl+0x62/0x78
       [<ffffffff803489b9>] blkdev_ioctl+0x65b/0x6b7
       [<ffffffff802e4d49>] block_ioctl+0x1a/0x1f
       [<ffffffff80243db3>] do_ioctl+0x29/0x77
       [<ffffffff802326ff>] vfs_ioctl+0x259/0x277
       [<ffffffff8024ed14>] sys_ioctl+0x5e/0x82
       [<ffffffff8026094d>] system_call+0x7d/0x83

other info that might help us debug this:

1 lock held by init/1:
 #0:  (&new->reconfig_mutex){--..}, at: [<ffffffff80266425>]
mutex_lock_interruptible+0x2a/0x2e

stack backtrace:

Call Trace:
 [<ffffffff8026ed0d>] show_trace+0xae/0x336
 [<ffffffff8026efaa>] dump_stack+0x15/0x17
 [<ffffffff802a7930>] print_circular_bug_tail+0x6c/0x77
 [<ffffffff802a8eae>] __lock_acquire+0x7c2/0x9d9
 [<ffffffff802a9668>] lock_acquire+0x4b/0x69
 [<ffffffff80266649>] __mutex_lock_slowpath+0xe5/0x261
 [<ffffffff802667ef>] mutex_lock+0x2a/0x2e
 [<ffffffff802e5139>] bd_claim_by_disk+0x74/0x1c2
 [<ffffffff80411a56>] bind_rdev_to_array+0x213/0x23a
 [<ffffffff80413818>] autorun_devices+0x21a/0x316
 [<ffffffff804161e9>] md_ioctl+0x114/0x1431
 [<ffffffff80348349>] blkdev_driver_ioctl+0x63/0x78
 [<ffffffff803489ba>] blkdev_ioctl+0x65c/0x6b7
 [<ffffffff802e4d4a>] block_ioctl+0x1b/0x1f
 [<ffffffff80243db4>] do_ioctl+0x2a/0x77
 [<ffffffff80232700>] vfs_ioctl+0x25a/0x277
 [<ffffffff8024ed15>] sys_ioctl+0x5f/0x82
 [<ffffffff8026094e>] system_call+0x7e/0x83
DWARF2 unwinder stuck at system_call+0x7e/0x83
Leftover inexact backtrace:

md: bind<sdb2>
md: running: <sdb2><sda2>
raid1: raid set md2 active with 2 out of 2 mirrors
....


Version-Release number of selected component (if applicable):
kernel-2.6.18-1.2708.fc6

Comment 1 Dave Jones 2006-10-04 23:28:07 UTC
*** Bug 208840 has been marked as a duplicate of this bug. ***

Comment 2 Dave Jones 2006-10-04 23:29:08 UTC
*** Bug 208829 has been marked as a duplicate of this bug. ***

Comment 3 Kostas Georgiou 2006-10-20 12:15:22 UTC
Since it doesn't appear any more with the last few kernels can I assume it's
fixed and close the ticket or it's just the debugging code that's gone away?


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