Alexander Beregalov
2009-Feb-09 12:43 UTC
2.6.29-rc4: possible circular locking dependency at btrfs_try_spin_lock
Hi
Is it false positive lockdep warning?
[ INFO: possible circular locking dependency detected ]
2.6.29-rc4-00001-gd5b5623 #2
-------------------------------------------------------
dbench/2193 is trying to acquire lock:
(&eb->lock/7){--..}, at: [<ffffffff80448f1f>]
btrfs_try_spin_lock+0x8f/0x1a0
but task is already holding lock:
(&eb->lock#2/6){--..}, at: [<ffffffff80448df4>]
btrfs_tree_lock+0xc4/0x160
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&eb->lock#2/6){--..}:
[<ffffffff8026f3f3>] __lock_acquire+0xe23/0x1290
[<ffffffff8026f8f1>] lock_acquire+0x91/0xc0
[<ffffffff8062ed06>] _spin_lock_nested+0x46/0x80
[<ffffffff80448d1d>] btrfs_clear_lock_blocking+0x9d/0xb0
[<ffffffff80400b72>] btrfs_clear_path_blocking+0x32/0x50
[<ffffffff804095b2>] btrfs_search_slot+0x9a2/0xb10
[<ffffffff80409d54>] btrfs_insert_empty_items+0xa4/0x4e0
[<ffffffff80423f26>] btrfs_new_inode+0x156/0x350
[<ffffffff8042540f>] btrfs_mkdir+0x10f/0x210
[<ffffffff802d1fdc>] vfs_mkdir+0x8c/0xd0
[<ffffffff802d4156>] sys_mkdirat+0x106/0x120
[<ffffffff802d4183>] sys_mkdir+0x13/0x20
[<ffffffff8020be1b>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
-> #0 (&eb->lock/7){--..}:
[<ffffffff8026f4ba>] __lock_acquire+0xeea/0x1290
[<ffffffff8026f8f1>] lock_acquire+0x91/0xc0
[<ffffffff8062ed06>] _spin_lock_nested+0x46/0x80
[<ffffffff80448f1f>] btrfs_try_spin_lock+0x8f/0x1a0
[<ffffffff8040911e>] btrfs_search_slot+0x50e/0xb10
[<ffffffff80418b93>] btrfs_lookup_xattr+0x83/0x110
[<ffffffff80438044>] __btrfs_getxattr+0x74/0x120
[<ffffffff8044f37c>] btrfs_get_acl+0xbc/0x160
[<ffffffff8044f62d>] btrfs_init_acl+0x9d/0x180
[<ffffffff80422eec>] btrfs_init_inode_security+0x1c/0x40
[<ffffffff80425458>] btrfs_mkdir+0x158/0x210
[<ffffffff802d1fdc>] vfs_mkdir+0x8c/0xd0
[<ffffffff802d4156>] sys_mkdirat+0x106/0x120
[<ffffffff802d4183>] sys_mkdir+0x13/0x20
[<ffffffff8020be1b>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
other info that might help us debug this:
2 locks held by dbench/2193:
#0: (&sb->s_type->i_mutex_key#12/1){--..}, at:
[<ffffffff802d0c00>]
lookup_create+0x30/0xd0
#1: (&eb->lock#2/6){--..}, at: [<ffffffff80448df4>]
btrfs_tree_lock+0xc4/0x160
stack backtrace:
Pid: 2193, comm: dbench Not tainted 2.6.29-rc4-00001-gd5b5623 #2
Call Trace:
[<ffffffff8026cfa7>] print_circular_bug_tail+0xa7/0x100
[<ffffffff8026f4ba>] __lock_acquire+0xeea/0x1290
[<ffffffff8026f8f1>] lock_acquire+0x91/0xc0
[<ffffffff80448f1f>] ? btrfs_try_spin_lock+0x8f/0x1a0
[<ffffffff8062ed06>] _spin_lock_nested+0x46/0x80
[<ffffffff80448f1f>] ? btrfs_try_spin_lock+0x8f/0x1a0
[<ffffffff80448f1f>] btrfs_try_spin_lock+0x8f/0x1a0
[<ffffffff8040911e>] btrfs_search_slot+0x50e/0xb10
[<ffffffff8045eec5>] ? crypto_shash_update+0x25/0x30
[<ffffffff8048150c>] ? crc32c+0x4c/0x60
[<ffffffff80418b93>] btrfs_lookup_xattr+0x83/0x110
[<ffffffff802c3885>] ? kmem_cache_alloc+0xb5/0x100
[<ffffffff8026e37d>] ? trace_hardirqs_on+0xd/0x10
[<ffffffff80438044>] __btrfs_getxattr+0x74/0x120
[<ffffffff8044f37c>] btrfs_get_acl+0xbc/0x160
[<ffffffff8044f62d>] btrfs_init_acl+0x9d/0x180
[<ffffffff8062cf59>] ? mutex_unlock+0x9/0x10
[<ffffffff80422eec>] btrfs_init_inode_security+0x1c/0x40
[<ffffffff80425458>] btrfs_mkdir+0x158/0x210
[<ffffffff802d1fdc>] vfs_mkdir+0x8c/0xd0
[<ffffffff802d4156>] sys_mkdirat+0x106/0x120
[<ffffffff8020be4c>] ? sysret_check+0x27/0x62
[<ffffffff8020be4c>] ? sysret_check+0x27/0x62
[<ffffffff8026e312>] ? trace_hardirqs_on_caller+0x182/0x1e0
[<ffffffff802d4183>] sys_mkdir+0x13/0x20
[<ffffffff8020be1b>] system_call_fastpath+0x16/0x1b
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Alexander Beregalov
2009-Feb-09 13:48 UTC
Re: 2.6.29-rc4: possible circular locking dependency at btrfs_try_spin_lock
2009/2/9 Alexander Beregalov <a.beregalov@gmail.com>:> Hi > Is it false positive lockdep warning? > > [ INFO: possible circular locking dependency detected ] > 2.6.29-rc4-00001-gd5b5623 #2 > -------------------------------------------------------Another one with linux-next [ INFO: possible circular locking dependency detected ] 2.6.29-rc4-next-20090209 #3 ------------------------------------------------------- dbench/31903 is trying to acquire lock: (&eb->lock#2/6){--..}, at: [<ffffffff80447bbd>] btrfs_clear_lock_blocking+0x9d/0xb0 but task is already holding lock: (&eb->lock/7){--..}, at: [<ffffffff80447bbd>] btrfs_clear_lock_blocking+0x9d/0xb0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&eb->lock/7){--..}: [<ffffffff8026d3d3>] __lock_acquire+0xe23/0x1290 [<ffffffff8026d8d1>] lock_acquire+0x91/0xc0 [<ffffffff8062f8c6>] _spin_lock_nested+0x46/0x80 [<ffffffff80447dbf>] btrfs_try_spin_lock+0x8f/0x1a0 [<ffffffff80407f3e>] btrfs_search_slot+0x50e/0xb10 [<ffffffff80414447>] btrfs_read_block_groups+0x67/0x390 [<ffffffff8041eb98>] open_ctree+0xe18/0x1120 [<ffffffff803fec78>] btrfs_get_sb+0x3a8/0x4b0 [<ffffffff802c8468>] vfs_kern_mount+0x58/0xd0 [<ffffffff802c854e>] do_kern_mount+0x4e/0x110 [<ffffffff802e1981>] do_mount+0x291/0x880 [<ffffffff802e2030>] sys_mount+0xc0/0x100 [<ffffffff8020bc1b>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff -> #0 (&eb->lock#2/6){--..}: [<ffffffff8026d49a>] __lock_acquire+0xeea/0x1290 [<ffffffff8026d8d1>] lock_acquire+0x91/0xc0 [<ffffffff8062f8c6>] _spin_lock_nested+0x46/0x80 [<ffffffff80447bbd>] btrfs_clear_lock_blocking+0x9d/0xb0 [<ffffffff803ff992>] btrfs_clear_path_blocking+0x32/0x50 [<ffffffff80407d81>] btrfs_search_slot+0x351/0xb10 [<ffffffff80408b74>] btrfs_insert_empty_items+0xa4/0x4e0 [<ffffffff8040df2a>] __btrfs_alloc_reserved_extent+0xea/0x330 [<ffffffff804137de>] btrfs_alloc_extent+0x6e/0xb0 [<ffffffff8041387c>] btrfs_alloc_free_block+0x5c/0x90 [<ffffffff804020a6>] __btrfs_cow_block+0x746/0xb00 [<ffffffff80402b62>] btrfs_cow_block+0x112/0x2d0 [<ffffffff80407c53>] btrfs_search_slot+0x223/0xb10 [<ffffffff80419b33>] btrfs_lookup_inode+0x33/0xb0 [<ffffffff80423146>] btrfs_update_inode+0x46/0xd0 [<ffffffff804243f5>] btrfs_dirty_inode+0x45/0x60 [<ffffffff802e6615>] __mark_inode_dirty+0x35/0x1c0 [<ffffffff802db3c8>] touch_atime+0xd8/0x140 [<ffffffff802d5e56>] vfs_readdir+0xc6/0xd0 [<ffffffff802d5fb7>] sys_getdents+0x87/0xe0 [<ffffffff8020bc1b>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff other info that might help us debug this: 2 locks held by dbench/31903: #0: (&type->i_mutex_dir_key#6){--..}, at: [<ffffffff802d5e04>] vfs_readdir+0x74/0xd0 #1: (&eb->lock/7){--..}, at: [<ffffffff80447bbd>] btrfs_clear_lock_blocking+0x9d/0xb0 stack backtrace: Pid: 31903, comm: dbench Not tainted 2.6.29-rc4-next-20090209 #3 Call Trace: [<ffffffff8026b0ef>] print_circular_bug_tail+0x9f/0xf0 [<ffffffff8026d49a>] __lock_acquire+0xeea/0x1290 [<ffffffff8026d8d1>] lock_acquire+0x91/0xc0 [<ffffffff80447bbd>] ? btrfs_clear_lock_blocking+0x9d/0xb0 [<ffffffff80447bbd>] ? btrfs_clear_lock_blocking+0x9d/0xb0 [<ffffffff8062f8c6>] _spin_lock_nested+0x46/0x80 [<ffffffff80447bbd>] ? btrfs_clear_lock_blocking+0x9d/0xb0 [<ffffffff80447bbd>] btrfs_clear_lock_blocking+0x9d/0xb0 [<ffffffff803ff992>] btrfs_clear_path_blocking+0x32/0x50 [<ffffffff80407d81>] btrfs_search_slot+0x351/0xb10 [<ffffffff802191da>] ? save_stack_trace+0x2a/0x50 [<ffffffff8040dea0>] ? __btrfs_alloc_reserved_extent+0x60/0x330 [<ffffffff80408b74>] btrfs_insert_empty_items+0xa4/0x4e0 [<ffffffff8026c2f2>] ? trace_hardirqs_on_caller+0x182/0x1e0 [<ffffffff8026c35d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff8040df2a>] __btrfs_alloc_reserved_extent+0xea/0x330 [<ffffffff804137de>] btrfs_alloc_extent+0x6e/0xb0 [<ffffffff8041387c>] btrfs_alloc_free_block+0x5c/0x90 [<ffffffff804020a6>] __btrfs_cow_block+0x746/0xb00 [<ffffffff80402b62>] btrfs_cow_block+0x112/0x2d0 [<ffffffff80407c53>] btrfs_search_slot+0x223/0xb10 [<ffffffff8026c056>] ? mark_held_locks+0x56/0xa0 [<ffffffff802c2b45>] ? kmem_cache_alloc+0xb5/0x100 [<ffffffff80419b33>] btrfs_lookup_inode+0x33/0xb0 [<ffffffff80423146>] btrfs_update_inode+0x46/0xd0 [<ffffffff802d5bd0>] ? filldir+0x0/0xe0 [<ffffffff804243f5>] btrfs_dirty_inode+0x45/0x60 [<ffffffff802e6615>] __mark_inode_dirty+0x35/0x1c0 [<ffffffff802db3c8>] touch_atime+0xd8/0x140 [<ffffffff802d5e56>] vfs_readdir+0xc6/0xd0 [<ffffffff802d5fb7>] sys_getdents+0x87/0xe0 [<ffffffff8020bc1b>] system_call_fastpath+0x16/0x1b -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Chris Mason
2009-Feb-09 14:47 UTC
Re: 2.6.29-rc4: possible circular locking dependency at btrfs_try_spin_lock
On Mon, 2009-02-09 at 15:43 +0300, Alexander Beregalov wrote:> Hi > Is it false positive lockdep warning? >Interesting, lockdep must be smarter in linux-next. It''s a false positive, I''ll try to fix it up. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html