Bug 208829 - lockdep warning during raid0 autodetection.
lockdep warning during raid0 autodetection.
Status: CLOSED DUPLICATE of bug 208732
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-02 05:26 EDT by Dave Jones
Modified: 2015-01-04 17:28 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-04 19:29:05 EDT
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 Dave Jones 2006-10-02 05:26:03 EDT
=======================================================
[ 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:
Comment 1 Peter Zijlstra 2006-10-02 09:13:06 EDT
http://lkml.org/lkml/2006/9/29/123
Comment 2 Dave Jones 2006-10-04 19:29:05 EDT

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

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