INFO: possible recursive locking detected

INFO: possible recursive locking detected

[Jason Dravet]

On a recent attempted install of fedora's rawhide I saw the following in my 
anaconda.log file.

<4>=============================================
<4>[ INFO: possible recursive locking detected ]
<4>2.6.17-1.2571.fc6 #1
<4>---------------------------------------------
<4>anaconda/432 is trying to acquire lock:
<4> (&bdev->bd_mutex){--..}, at: [<c04658bb>] __blkdev_put+0x1f/0x11f
<4>
<4>but task is already holding lock:
<4> (&bdev->bd_mutex){--..}, at: [<c0465b4e>] do_open+0x6b/0x3b2
<4>
<4>other info that might help us debug this:
<4>1 lock held by anaconda/432:
<4> #0:  (&bdev->bd_mutex){--..}, at: [<c0465b4e>] do_open+0x6b/0x3b2
<4>
<4>stack backtrace:
<4> [<c04037db>] show_trace_log_lvl+0x58/0x159
<4> [<c0403d9e>] show_trace+0xd/0x10
<4> [<c0403e3b>] dump_stack+0x19/0x1b
<4> [<c042bddb>] __lock_acquire+0x765/0x97c
<4> [<c042c563>] lock_acquire+0x4b/0x6c
<4> [<c05f37ee>] mutex_lock_nested+0xcb/0x214
<4> [<c04658bb>] __blkdev_put+0x1f/0x11f
<4> [<c04659d4>] blkdev_put+0xa/0xc
<4> [<c0465e26>] do_open+0x343/0x3b2
<4> [<c0466030>] blkdev_open+0x1f/0x48
<4> [<c045d83c>] __dentry_open+0xb8/0x186
<4> [<c045d978>] nameidata_to_filp+0x1c/0x2e
<4> [<c045d9b9>] do_filp_open+0x2f/0x36
<4> [<c045da00>] do_sys_open+0x40/0xbb
<4> [<c045daa7>] sys_open+0x16/0x18
<4> [<c0402e57>] syscall_call+0x7/0xb
<4>DWARF2 unwinder stuck at syscall_call+0x7/0xb
<4>Leftover inexact backtrace:
<4> [<c0403d9e>] show_trace+0xd/0x10
<4> [<c0403e3b>] dump_stack+0x19/0x1b
<4> [<c042bddb>] __lock_acquire+0x765/0x97c
<4> [<c042c563>] lock_acquire+0x4b/0x6c
<4> [<c05f37ee>] mutex_lock_nested+0xcb/0x214
<4> [<c04658bb>] __blkdev_put+0x1f/0x11f
<4> [<c04659d4>] blkdev_put+0xa/0xc
<4> [<c0465e26>] do_open+0x343/0x3b2
<4> [<c0466030>] blkdev_open+0x1f/0x48
<4> [<c045d83c>] __dentry_open+0xb8/0x186
<4> [<c045d978>] nameidata_to_filp+0x1c/0x2e
<4> [<c045d9b9>] do_filp_open+0x2f/0x36
<4> [<c045da00>] do_sys_open+0x40/0xbb
<4> [<c045daa7>] sys_open+0x16/0x18
<4> [<c0402e57>] syscall_call+0x7/0xb

Also posted at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203137

INFO: possible recursive locking detected

[Justin P. Mattock]

this is on the current Mainline:
dmesg here: http://fpaste.org/khwR/


[  860.020044]
[  860.020044] =============================================
[  860.020044] [ INFO: possible recursive locking detected ]
[  860.020044] 3.0.0-rc4-00052-gbccaeaf #2
[  860.020044] ---------------------------------------------
[  860.020044] bash/2254 is trying to acquire lock:
[  860.020044]  (&(lock)->rlock){-.-...}, at: [<ffffffff812730a3>] 
acpi_os_acquire_lock+0xe/0x10
[  860.020044]
[  860.020044] but task is already holding lock:
[  860.020044]  (&(lock)->rlock){-.-...}, at: [<ffffffff812730a3>] 
acpi_os_acquire_lock+0xe/0x10
[  860.020044]
[  860.020044] other info that might help us debug this:
[  860.020044]  Possible unsafe locking scenario:
[  860.020044]
[  860.020044]        CPU0
[  860.020044]        ----
[  860.020044]   lock(&(lock)->rlock);
[  860.020044]   lock(&(lock)->rlock);
[  860.020044]
[  860.020044]  *** DEADLOCK ***
[  860.020044]
[  860.020044]  May be due to missing lock nesting notation
[  860.020044]
[  860.020044] 4 locks held by bash/2254:
[  860.020044]  #0:  (&buffer->mutex){+.+.+.}, at: [<ffffffff8117965a>] 
sysfs_write_file+0x3c/0x144
[  860.020044]  #1:  (s_active#160){.+.+.+}, at: [<ffffffff81179705>] 
sysfs_write_file+0xe7/0x144
[  860.020044]  #2:  (pm_mutex){+.+.+.}, at: [<ffffffff8108828e>] 
enter_state+0x34/0x137
[  860.020044]  #3:  (&(lock)->rlock){-.-...}, at: [<ffffffff812730a3>] 
acpi_os_acquire_lock+0xe/0x10
[  860.020044]
[  860.020044] stack backtrace:
[  860.020044] Pid: 2254, comm: bash Not tainted 3.0.0-rc4-00052-gbccaeaf #2
[  860.020044] Call Trace:
[  860.020044]  [<ffffffff8107b80d>] __lock_acquire+0x903/0xce3
[  860.020044]  [<ffffffff8107b3e6>] ? __lock_acquire+0x4dc/0xce3
[  860.020044]  [<ffffffff812730a3>] ? acpi_os_acquire_lock+0xe/0x10
[  860.020044]  [<ffffffff8107c04d>] lock_acquire+0xbf/0x103
[  860.020044]  [<ffffffff812730a3>] ? acpi_os_acquire_lock+0xe/0x10
[  860.020044]  [<ffffffff8128a1d8>] ? 
acpi_hw_enable_runtime_gpe_block+0x48/0x48
[  860.020044]  [<ffffffff814a0625>] _raw_spin_lock_irqsave+0x3f/0x52
[  860.020044]  [<ffffffff812730a3>] ? acpi_os_acquire_lock+0xe/0x10
[  860.020044]  [<ffffffff812730a3>] acpi_os_acquire_lock+0xe/0x10
[  860.020044]  [<ffffffff8128384c>] acpi_ev_walk_gpe_list+0x28/0x92
[  860.020044]  [<ffffffff8128a8ac>] acpi_hw_clear_acpi_status+0x3e/0x5a
[  860.020044]  [<ffffffff8101e33e>] ? paravirt_read_msr+0x10/0x14
[  860.020044]  [<ffffffff8128ac7b>] acpi_enter_sleep_state+0x90/0x1d6
[  860.020044]  [<ffffffff813dff84>] ? paravirt_read_msr+0x10/0x14
[  860.020044]  [<ffffffff8101f5ba>] do_suspend_lowlevel+0x9a/0x9c
[  860.020044]  [<ffffffff8101f4a8>] ? acpi_suspend_lowlevel+0x1b0/0x1c8
[  860.020044]  [<ffffffff81274056>] acpi_suspend_enter+0x37/0x96
[  860.020044]  [<ffffffff810881c0>] suspend_devices_and_enter+0x13f/0x1d9
[  860.020044]  [<ffffffff8108833a>] enter_state+0xe0/0x137
[  860.020044]  [<ffffffff8108793c>] state_store+0xaf/0xc5
[  860.020044]  [<ffffffff812265af>] kobj_attr_store+0x17/0x19
[  860.020044]  [<ffffffff81179726>] sysfs_write_file+0x108/0x144
[  860.020044]  [<ffffffff8111d577>] vfs_write+0xac/0xf3
[  860.020044]  [<ffffffff8111e974>] ? fget_light+0x3a/0x9c
[  860.020044]  [<ffffffff8111d766>] sys_write+0x4a/0x6e
[  860.020044]  [<ffffffff814a7682>] system_call_fastpath+0x16/0x1b

positive side is the previous pull I had with the Mainline rebooted upon 
wakeup. Now the machine wakes up and runs normally(minus the INFO thing)
In any let me know if you need any info.

Justin P. Mattock