Bug 15603 - lockdep warning at boot time when determining whether to resume
lockdep warning at boot time when determining whether to resume
Status: CLOSED WILL_NOT_FIX
Product: File System
Classification: Unclassified
Component: SysFS
All Linux
: P1 normal
Assigned To: Greg Kroah-Hartman
:
Depends on:
Blocks: 7216 15310
  Show dependency treegraph
 
Reported: 2010-03-22 00:03 UTC by Sami Liedes
Modified: 2010-04-08 18:37 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.33.1, 2.6.33.2
Tree: Mainline
Regression: Yes


Attachments
Entire dmesg output (54.04 KB, text/plain)
2010-03-22 00:03 UTC, Sami Liedes
Details

Description Sami Liedes 2010-03-22 00:03:21 UTC
Created attachment 25634 [details]
Entire dmesg output

I get a lockdep warning at boot time, after "PM: Starting manual resume from disk" (it was a clean boot, not resuming). The system does boot normally though.

Here's the warning:

------------------------------------------------------------
[   12.095635] PM: Starting manual resume from disk
[   12.095855] 
[   12.095856] =======================================================
[   12.096006] [ INFO: possible circular locking dependency detected ]
[   12.096006] 2.6.33.1-lap #1
[   12.096006] -------------------------------------------------------
[   12.096006] resume/1035 is trying to acquire lock:
[   12.096006]  (&bdev->bd_mutex){+.+.+.}, at: [<ffffffff8111561c>] __blkdev_get+0x6c/0x377
[   12.096006] 
[   12.096006] but task is already holding lock:
[   12.096006]  (pm_mutex/1){+.+...}, at: [<ffffffff8107ca54>] software_resume+0x2e/0x2ec
[   12.096006] 
[   12.096006] which lock already depends on the new lock.
[   12.096006] 
[   12.096006] 
[   12.096006] the existing dependency chain (in reverse order) is:
[   12.096006] 
[   12.096006] -> #2 (pm_mutex/1){+.+...}:
[   12.096006]        [<ffffffff8106f947>] __lock_acquire+0x127d/0x1607
[   12.096006]        [<ffffffff8106fd9d>] lock_acquire+0xcc/0xe9
[   12.096006]        [<ffffffff81432a01>] mutex_lock_nested+0x5e/0x2b1
[   12.096006]        [<ffffffff8107ca54>] software_resume+0x2e/0x2ec
[   12.096006]        [<ffffffff8107cda8>] resume_store+0x96/0xa7
[   12.096006]        [<ffffffff8123586f>] kobj_attr_store+0x17/0x19
[   12.096006]        [<ffffffff81141270>] sysfs_write_file+0x108/0x144
[   12.096006]        [<ffffffff810edd09>] vfs_write+0xb2/0x153
[   12.096006]        [<ffffffff810ede6d>] sys_write+0x4a/0x71
[   12.096006]        [<ffffffff81002b5b>] system_call_fastpath+0x16/0x1b
[   12.096006] 
[   12.096006] -> #1 (s_active){++++.+}:
[   12.096006]        [<ffffffff8106f947>] __lock_acquire+0x127d/0x1607
[   12.096006]        [<ffffffff8106fd9d>] lock_acquire+0xcc/0xe9
[   12.096006]        [<ffffffff81141df5>] sysfs_deactivate+0x8b/0xc8
[   12.096006]        [<ffffffff81142761>] sysfs_addrm_finish+0x36/0x5f
[   12.096006]        [<ffffffff8114092a>] sysfs_hash_and_remove+0x53/0x6a
[   12.096006]        [<ffffffff81142c0b>] sysfs_remove_link+0x21/0x23
[   12.096006]        [<ffffffff8111497b>] bd_release_from_disk+0xb7/0x133
[   12.096006]        [<ffffffff8138129f>] close_dev+0x2c/0x45
[   12.096006]        [<ffffffff813812e4>] dm_put_device+0x2c/0x68
[   12.096006]        [<ffffffff81386ece>] crypt_dtr+0x95/0xa2
[   12.096006]        [<ffffffff813817b1>] dm_table_destroy+0x6c/0xee
[   12.096006]        [<ffffffff8137f193>] dm_put+0xed/0x1ce
[   12.096006]        [<ffffffff81384160>] dev_remove+0xb9/0xcd
[   12.096006]        [<ffffffff813847de>] ctl_ioctl+0x1cf/0x227
[   12.096006]        [<ffffffff81384849>] dm_ctl_ioctl+0x13/0x17
[   12.096006]        [<ffffffff810fac33>] vfs_ioctl+0x32/0xa6
[   12.096006]        [<ffffffff810fb1c5>] do_vfs_ioctl+0x495/0x4db
[   12.096006]        [<ffffffff810fb252>] sys_ioctl+0x47/0x6a
[   12.096006]        [<ffffffff81002b5b>] system_call_fastpath+0x16/0x1b
[   12.096006] 
[   12.096006] -> #0 (&bdev->bd_mutex){+.+.+.}:
[   12.096006]        [<ffffffff8106f5f7>] __lock_acquire+0xf2d/0x1607
[   12.096006]        [<ffffffff8106fd9d>] lock_acquire+0xcc/0xe9
[   12.096006]        [<ffffffff81432a01>] mutex_lock_nested+0x5e/0x2b1
[   12.096006]        [<ffffffff8111561c>] __blkdev_get+0x6c/0x377
[   12.096006]        [<ffffffff81115937>] blkdev_get+0x10/0x12
[   12.096006]        [<ffffffff81115a8c>] open_by_devnum+0x2e/0x3f
[   12.096006]        [<ffffffff8107f23e>] swsusp_check+0x22/0x168
[   12.096006]        [<ffffffff8107cb10>] software_resume+0xea/0x2ec
[   12.096006]        [<ffffffff8107cda8>] resume_store+0x96/0xa7
[   12.096006]        [<ffffffff8123586f>] kobj_attr_store+0x17/0x19
[   12.096006]        [<ffffffff81141270>] sysfs_write_file+0x108/0x144
[   12.096006]        [<ffffffff810edd09>] vfs_write+0xb2/0x153
[   12.096006]        [<ffffffff810ede6d>] sys_write+0x4a/0x71
[   12.096006]        [<ffffffff81002b5b>] system_call_fastpath+0x16/0x1b
[   12.096006] 
[   12.096006] other info that might help us debug this:
[   12.096006] 
[   12.096006] 4 locks held by resume/1035:
[   12.096006]  #0:  (&buffer->mutex){+.+.+.}, at: [<ffffffff811411a4>] sysfs_write_file+0x3c/0x144
[   12.096006]  #1:  (s_active){++++.+}, at: [<ffffffff81142a2c>] sysfs_get_active_two+0x24/0x48
[   12.096006]  #2:  (s_active){++++.+}, at: [<ffffffff81142a39>] sysfs_get_active_two+0x31/0x48
[   12.096006]  #3:  (pm_mutex/1){+.+...}, at: [<ffffffff8107ca54>] software_resume+0x2e/0x2ec
[   12.096006] 
[   12.096006] stack backtrace:
[   12.096006] Pid: 1035, comm: resume Tainted: G        W  2.6.33.1-lap #1
[   12.096006] Call Trace:
[   12.096006]  [<ffffffff8106d789>] print_circular_bug+0xae/0xbd
[   12.096006]  [<ffffffff8106f5f7>] __lock_acquire+0xf2d/0x1607
[   12.096006]  [<ffffffff8106fa96>] ? __lock_acquire+0x13cc/0x1607
[   12.096006]  [<ffffffff8106fd9d>] lock_acquire+0xcc/0xe9
[   12.096006]  [<ffffffff8111561c>] ? __blkdev_get+0x6c/0x377
[   12.096006]  [<ffffffff8106d0e6>] ? trace_hardirqs_on+0xd/0xf
[   12.096006]  [<ffffffff81432a01>] mutex_lock_nested+0x5e/0x2b1
[   12.096006]  [<ffffffff8111561c>] ? __blkdev_get+0x6c/0x377
[   12.096006]  [<ffffffff8122a548>] ? exact_match+0x0/0xf
[   12.096006]  [<ffffffff8111561c>] __blkdev_get+0x6c/0x377
[   12.096006]  [<ffffffff81115937>] blkdev_get+0x10/0x12
[   12.096006]  [<ffffffff81115a8c>] open_by_devnum+0x2e/0x3f
[   12.096006]  [<ffffffff8107f23e>] swsusp_check+0x22/0x168
[   12.096006]  [<ffffffff8107cb10>] software_resume+0xea/0x2ec
[   12.096006]  [<ffffffff8107cda8>] resume_store+0x96/0xa7
[   12.096006]  [<ffffffff8123586f>] kobj_attr_store+0x17/0x19
[   12.096006]  [<ffffffff81141270>] sysfs_write_file+0x108/0x144
[   12.096006]  [<ffffffff810edd09>] vfs_write+0xb2/0x153
[   12.096006]  [<ffffffff8106d0b5>] ? trace_hardirqs_on_caller+0x10c/0x130
[   12.096006]  [<ffffffff810ede6d>] sys_write+0x4a/0x71
[   12.096006]  [<ffffffff81002b5b>] system_call_fastpath+0x16/0x1b
------------------------------------------------------------

Entire dmesg attached.
Comment 1 Rafael J. Wysocki 2010-03-22 00:06:18 UTC
This warning triggers as a result of recent sysfs changes.
Comment 2 Sami Liedes 2010-04-07 22:29:34 UTC
Still happens on 2.6.33.2.
Comment 3 Eric W. Biederman 2010-04-08 05:25:21 UTC
bugzilla-daemon@bugzilla.kernel.org writes:

> https://bugzilla.kernel.org/show_bug.cgi?id=15603
>
>
> Sami Liedes <sliedes@cc.hut.fi> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>      Kernel Version|2.6.33.1                    |2.6.33.1, 2.6.33.2
>
>
>
>
> --- Comment #2 from Sami Liedes <sliedes@cc.hut.fi>  2010-04-07 22:29:34 ---
> Still happens on 2.6.33.2.

Lockdep warns about possible locking problems.

Unfortunately the initial version of this lockdep warning had a high
false positive rate.  In the latest versions of 2.6.34-rcX the deeper
changes needed to remove those false positives have been made.  If you
are interested in seeing the warning go away I suggest you try that.
If a problem persists in 2.6.34-rcX it is almost certainly a real
locking problem.

No changes are planned for 2.6.33.x as this is believed to be a false
positive, and can easily be avoided by simply turning off lockdep.

Eric
Comment 4 Rafael J. Wysocki 2010-04-08 18:36:37 UTC
Yes, we're not going to fix this in 2.6.33.x, so closing.

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