Bug 731361 - possible recursive locking in btrfs
Summary: possible recursive locking in btrfs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 16
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Josef Bacik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 729904 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-17 12:45 UTC by Mikko Tiihonen
Modified: 2012-01-31 14:17 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-31 14:17:14 UTC


Attachments (Terms of Use)

Description Mikko Tiihonen 2011-08-17 12:45:15 UTC
Description of problem:
[ INFO: possible recursive locking detected ]
3.0.1-3.fc16.x86_64 #1
---------------------------------------------
gnome-settings-/1594 is trying to acquire lock:
 (&(&eb->lock)->rlock){+.+...}, at: [<ffffffffa019c4cc>] btrfs_try_spin_lock+0x27/0x83 [btrfs]

but task is already holding lock:
 (&(&eb->lock)->rlock){+.+...}, at: [<ffffffffa019c49c>] btrfs_clear_lock_blocking+0x1f/0x28 [btrfs]

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&(&eb->lock)->rlock);
  lock(&(&eb->lock)->rlock);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

2 locks held by gnome-settings-/1594:
 #0:  (&sb->s_type->i_mutex_key#13){+.+.+.}, at: [<ffffffff8114568d>] walk_component+0x1e8/0x3b4
 #1:  (&(&eb->lock)->rlock){+.+...}, at: [<ffffffffa019c49c>] btrfs_clear_lock_blocking+0x1f/0x28 [btrfs]

stack backtrace:
Pid: 1594, comm: gnome-settings- Not tainted 3.0.1-3.fc16.x86_64 #1
Call Trace:
 [<ffffffff8108a3b9>] __lock_acquire+0x917/0xcf7
 [<ffffffff8100e9fd>] ? paravirt_read_tsc+0x9/0xd
 [<ffffffff8100eec7>] ? native_sched_clock+0x34/0x36
 [<ffffffff8100eed2>] ? sched_clock+0x9/0xd
 [<ffffffffa019c49c>] ? btrfs_clear_lock_blocking+0x1f/0x28 [btrfs]
 [<ffffffffa019c4cc>] ? btrfs_try_spin_lock+0x27/0x83 [btrfs]
 [<ffffffff8108ac26>] lock_acquire+0xbf/0x103
 [<ffffffffa019c4cc>] ? btrfs_try_spin_lock+0x27/0x83 [btrfs]
 [<ffffffff814dcaf8>] _raw_spin_lock+0x36/0x6a
 [<ffffffffa019c4cc>] ? btrfs_try_spin_lock+0x27/0x83 [btrfs]
 [<ffffffffa019c49c>] ? btrfs_clear_lock_blocking+0x1f/0x28 [btrfs]
 [<ffffffffa019c4cc>] btrfs_try_spin_lock+0x27/0x83 [btrfs]
 [<ffffffffa015cd30>] btrfs_search_slot+0x37b/0x499 [btrfs]
 [<ffffffff8108b029>] ? trace_hardirqs_on_caller+0x10b/0x12f
 [<ffffffffa016a1cb>] btrfs_lookup_dir_item+0x75/0xd6 [btrfs]
 [<ffffffffa017c872>] btrfs_lookup_dentry+0x8d/0x3d0 [btrfs]
 [<ffffffff8108ab3e>] ? lock_release+0x173/0x19c
 [<ffffffffa017cbc8>] btrfs_lookup+0x13/0x2a [btrfs]
 [<ffffffff81144235>] d_alloc_and_lookup+0x45/0x6b
 [<ffffffff811456b3>] walk_component+0x20e/0x3b4
 [<ffffffff81146435>] do_last+0x119/0x583
 [<ffffffff81147457>] path_openat+0xcb/0x31f
 [<ffffffff8100eec7>] ? native_sched_clock+0x34/0x36
 [<ffffffff8100eed2>] ? sched_clock+0x9/0xd
 [<ffffffff811476e3>] do_filp_open+0x38/0x86
 [<ffffffff814dd36d>] ? _raw_spin_unlock+0x28/0x2c
 [<ffffffff81152080>] ? alloc_fd+0x17f/0x191
 [<ffffffff8113a5cf>] do_sys_open+0x6e/0x100
 [<ffffffff8113a681>] sys_open+0x20/0x22
 [<ffffffff814e3ec2>] system_call_fastpath+0x16/0x1b

Comment 1 Josh Boyer 2011-09-06 15:38:00 UTC
*** Bug 729904 has been marked as a duplicate of this bug. ***

Comment 2 Matthias Runge 2011-09-07 06:21:20 UTC
Version-Release number of selected component (if applicable):

3.0.1-3.fc16.i686.PAE
btrfs-progs-0.19-13.fc15.i686

I've seen this even without btrfs involvation, so I guess, it's not necessarily btrfs related.

Comment 3 Dave Jones 2012-01-30 19:34:10 UTC
is this still happening on the 3.2 kernel ?

Comment 4 Mikko Tiihonen 2012-01-31 10:43:15 UTC
It was fixed in 3.2 kernel

Comment 5 Josh Boyer 2012-01-31 14:17:14 UTC
Thank you for letting us know.


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