Bug 796597

Summary: possible circular locking dependency &type->s_umount_key -->&fs_info->cleaner_mutex
Product: [Fedora] Fedora Reporter: Mikko Tiihonen <mikko.tiihonen>
Component: kernelAssignee: Zach Brown <zab>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, sweil
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: first=3.3.0.rc3.git7 btrfs lockdep hibernate
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-07-12 14:34:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 781749    

Description Mikko Tiihonen 2012-02-23 09:55:24 UTC
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 12:44:42 UTC
Josef, have you seen anything like this yet?

Comment 2 Josh Boyer 2012-03-28 18:00:34 UTC
[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 22:37:07 UTC
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 11:04:18 UTC
This bug no longer occurs on kernel-3.5.0-0.rc6.git2.1.fc18 (which has lockdep enabled) when I hibernate.