Bug 796597 - possible circular locking dependency &type->s_umount_key -->&fs_info->cleaner_mutex
possible circular locking dependency &type->s_umount_key -->&fs_info->cleaner...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
17
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Zach Brown
Fedora Extras Quality Assurance
first=3.3.0.rc3.git7 btrfs lockdep hi...
:
Depends On:
Blocks: kernel_hibernate
  Show dependency treegraph
 
Reported: 2012-02-23 04:55 EST by Mikko Tiihonen
Modified: 2015-05-17 21:40 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-07-12 10:34:04 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 Mikko Tiihonen 2012-02-23 04:55:24 EST
This occured when resuming from hibernate (actually the first successfull resume on this laptop ever!).

Version-Release number of selected component (if applicable):
kernel-3.3.0-0.rc3.git7.2.fc17

[ INFO: possible circular locking dependency detected ]
3.3.0-0.rc3.git7.2.fc17.x86_64 #1 Not tainted
-------------------------------------------------------
pm-hibernate/8930 is trying to acquire lock:
 (&type->s_umount_key#19){+++++.}, at: [<ffffffff811be5a8>] thaw_super+0x28/0xd0

but task is already holding lock:
 (&fs_info->cleaner_mutex){+.+.+.}, at: [<ffffffffa01abdf1>] btrfs_freeze+0x31/0x40 [btrfs]

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (&fs_info->cleaner_mutex){+.+.+.}:
       [<ffffffff810ccb91>] lock_acquire+0xa1/0x1e0
       [<ffffffff8169a316>] mutex_lock_nested+0x76/0x3a0
       [<ffffffffa01d0bf6>] btrfs_commit_super+0x26/0xd0 [btrfs]
       [<ffffffffa01d2670>] close_ctree+0x2a0/0x310 [btrfs]
       [<ffffffffa01ac039>] btrfs_put_super+0x19/0x20 [btrfs]
       [<ffffffff811bea01>] generic_shutdown_super+0x61/0xf0
       [<ffffffff811beb26>] kill_anon_super+0x16/0x30
       [<ffffffffa01afd0a>] btrfs_kill_super+0x1a/0x90 [btrfs]
       [<ffffffff811be547>] deactivate_locked_super+0x57/0x90
       [<ffffffff811be7be>] deactivate_super+0x4e/0x70
       [<ffffffff811ddcf1>] mntput_no_expire+0xb1/0x100
       [<ffffffff811dea66>] sys_umount+0x76/0x370
       [<ffffffff816a6f29>] system_call_fastpath+0x16/0x1b

-> #0 (&type->s_umount_key#19){+++++.}:
       [<ffffffff810cbdc8>] __lock_acquire+0x13d8/0x1ad0
       [<ffffffff810ccb91>] lock_acquire+0xa1/0x1e0
       [<ffffffff8169b721>] down_write+0x61/0xb0
       [<ffffffff811be5a8>] thaw_super+0x28/0xd0
       [<ffffffff811bf9d8>] thaw_supers+0xb8/0xd0
       [<ffffffff810b6482>] hibernate+0x122/0x220
       [<ffffffff810b38cc>] state_store+0x10c/0x130
       [<ffffffff8131eecf>] kobj_attr_store+0xf/0x20
       [<ffffffff812347b6>] sysfs_write_file+0xe6/0x160
       [<ffffffff811bb44f>] vfs_write+0xaf/0x190
       [<ffffffff811bb78d>] sys_write+0x4d/0x90
       [<ffffffff816a6f29>] system_call_fastpath+0x16/0x1b

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&fs_info->cleaner_mutex);
                               lock(&type->s_umount_key#19);
                               lock(&fs_info->cleaner_mutex);
  lock(&type->s_umount_key#19);

 *** DEADLOCK ***

5 locks held by pm-hibernate/8930:
 #0:  (&buffer->mutex){+.+.+.}, at: [<ffffffff81234718>] sysfs_write_file+0x48/0x160
 #1:  (s_active#109){.+.+.+}, at: [<ffffffff8123479b>] sysfs_write_file+0xcb/0x160
 #2:  (pm_mutex){+.+.+.}, at: [<ffffffff810b638c>] hibernate+0x2c/0x220
 #3:  (&fs_info->transaction_kthread_mutex){+.+.+.}, at: [<ffffffffa01abde3>] btrfs_freeze+0x23/0x40 [btrfs]
 #4:  (&fs_info->cleaner_mutex){+.+.+.}, at: [<ffffffffa01abdf1>] btrfs_freeze+0x31/0x40 [btrfs]

stack backtrace:
Pid: 8930, comm: pm-hibernate Not tainted 3.3.0-0.rc3.git7.2.fc17.x86_64 #1
Call Trace:
 [<ffffffff81692a4e>] print_circular_bug+0x1fb/0x20c
 [<ffffffff810cbdc8>] __lock_acquire+0x13d8/0x1ad0
 [<ffffffff81020ee3>] ? native_sched_clock+0x13/0x80
 [<ffffffff810ccb91>] lock_acquire+0xa1/0x1e0
 [<ffffffff811be5a8>] ? thaw_super+0x28/0xd0
 [<ffffffff8169b721>] down_write+0x61/0xb0
 [<ffffffff811be5a8>] ? thaw_super+0x28/0xd0
 [<ffffffff811be5a8>] thaw_super+0x28/0xd0
 [<ffffffff811bf9d8>] thaw_supers+0xb8/0xd0
 [<ffffffff810b6482>] hibernate+0x122/0x220
 [<ffffffff810b38cc>] state_store+0x10c/0x130
 [<ffffffff8131eecf>] kobj_attr_store+0xf/0x20
 [<ffffffff812347b6>] sysfs_write_file+0xe6/0x160
 [<ffffffff811bb44f>] vfs_write+0xaf/0x190
 [<ffffffff811bb78d>] sys_write+0x4d/0x90
 [<ffffffff816a6f29>] system_call_fastpath+0x16/0x1b
Comment 1 Josh Boyer 2012-02-23 07:44:42 EST
Josef, have you seen anything like this yet?
Comment 2 Josh Boyer 2012-03-28 14:00:34 EDT
[Mass hibernate bug update]

Dave Airlied has found an issue causing some corruption in the i915 fbdev after a resume from hibernate.  I have included his patch in this scratch build:

http://koji.fedoraproject.org/koji/taskinfo?taskID=3940545

This will probably not solve all of the issues being tracked at the moment, but it is worth testing when the build completes.  If this seems to clear up the issues you see with hibernate, please report your results in the bug.
Comment 3 Dave Jones 2012-06-18 18:37:07 EDT
Mikko, is this still happening (note, you need to run the kernel-debug package to see the lockdep reports, regular f17 build doesn't have it enabled).
Comment 4 Mikko Tiihonen 2012-07-12 07:04:18 EDT
This bug no longer occurs on kernel-3.5.0-0.rc6.git2.1.fc18 (which has lockdep enabled) when I hibernate.

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