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
*** Bug 729904 has been marked as a duplicate of this bug. ***
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.
is this still happening on the 3.2 kernel ?
It was fixed in 3.2 kernel
Thank you for letting us know.