Bug 208732 - circular dependency reported by md (bdev_part_lock_key / reconfig_mutex)
circular dependency reported by md (bdev_part_lock_key / reconfig_mutex)
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
: 208829 208840 (view as bug list)
Depends On:
Blocks: FCMETA_LOCKDEP
  Show dependency treegraph
 
Reported: 2006-09-30 23:49 EDT by Kostas Georgiou
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Kostas Georgiou 2006-09-30 23:49:36 EDT
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 19:28:07 EDT
*** Bug 208840 has been marked as a duplicate of this bug. ***
Comment 2 Dave Jones 2006-10-04 19:29:08 EDT
*** Bug 208829 has been marked as a duplicate of this bug. ***
Comment 3 Kostas Georgiou 2006-10-20 08:15:22 EDT
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.