Re: reiser4-2.6.18-rc2-mm1: possible circular locking dependency detected in txn_end

[Alexander Zarochentsev <zam@namesys.com>]

Hello Ingo,

there is a new reiser4 / lock validator problem:

On Sunday 30 July 2006 22:57, Laurent Riffard wrote:
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> -------------------------------------------------------
> mv/29012 is trying to acquire lock:
>  (&txnh->hlock){--..}, at: [<e0c8e09b>] txn_end+0x191/0x368 [reiser4]
>
> but task is already holding lock:
>  (&atom->alock){--..}, at: [<e0c8a640>] txnh_get_atom+0xf6/0x39e
> [reiser4]
>
> which lock already depends on the new lock.

it is absolutely legal in reiser4 to lock atom first, then lock 
transaction handle.

i guess the lock validator recorded wrong dependency rule from one place 
where the spinlocks are taken in reverse order.  that place is in 
fs/reiser4/txnmgr.c:atom_begin_and_assign_to_txnh, that atom is new, 
just kmalloc'ed object which is inaccessible for others, so it can't a 
source for deadlock.

but how to explain that to the lock validator?

>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (&atom->alock){--..}:
>        [<c012ce2f>] lock_acquire+0x60/0x80
>        [<c0292968>] _spin_lock+0x19/0x28
>        [<e0c8bbd7>] try_capture+0x7cf/0x1cd7 [reiser4]
>        [<e0c786e1>] longterm_lock_znode+0x427/0x84f [reiser4]
>        [<e0ca55dc>] coord_by_handle+0x2be/0x7f7 [reiser4]
>        [<e0ca5f89>] coord_by_key+0x1e3/0x22d [reiser4]
>        [<e0c7dbd2>] insert_by_key+0x8f/0xe0 [reiser4]
>        [<e0cbf7f1>] write_sd_by_inode_common+0x361/0x61a [reiser4]
>        [<e0cbfce4>] create_object_common+0xf1/0xf6 [reiser4]
>        [<e0cbaebf>] create_vfs_object+0x51d/0x732 [reiser4]
>        [<e0cbb1fd>] mkdir_common+0x43/0x4b [reiser4]
>        [<c015ed33>] vfs_mkdir+0x5a/0x9d
>        [<c0160f5e>] sys_mkdirat+0x88/0xc0
>        [<c0160fa6>] sys_mkdir+0x10/0x12
>        [<c0102c2d>] sysenter_past_esp+0x56/0x8d
>
> -> #0 (&txnh->hlock){--..}:
>        [<c012ce2f>] lock_acquire+0x60/0x80
>        [<c0292968>] _spin_lock+0x19/0x28
>        [<e0c8e09b>] txn_end+0x191/0x368 [reiser4]
>        [<e0c7f97d>] reiser4_exit_context+0x1c2/0x571 [reiser4]
>        [<e0cbb091>] create_vfs_object+0x6ef/0x732 [reiser4]
>        [<e0cbb1fd>] mkdir_common+0x43/0x4b [reiser4]
>        [<c015ed33>] vfs_mkdir+0x5a/0x9d
>        [<c0160f5e>] sys_mkdirat+0x88/0xc0
>        [<c0160fa6>] sys_mkdir+0x10/0x12
>        [<c0102c2d>] sysenter_past_esp+0x56/0x8d
>
> other info that might help us debug this:
>
> 2 locks held by mv/29012:
>  #0:  (&inode->i_mutex/1){--..}, at: [<c015f50b>]
> lookup_create+0x1d/0x73
>  #1:  (&atom->alock){--..}, at: [<e0c8a640>]
> txnh_get_atom+0xf6/0x39e [reiser4]
>
> stack backtrace:
>  [<c0104df0>] show_trace+0xd/0x10
>  [<c0104e0c>] dump_stack+0x19/0x1d
>  [<c012bc62>] print_circular_bug_tail+0x59/0x64
>  [<c012cc3e>] __lock_acquire+0x814/0x9a5
>  [<c012ce2f>] lock_acquire+0x60/0x80
>  [<c0292968>] _spin_lock+0x19/0x28
>  [<e0c8e09b>] txn_end+0x191/0x368 [reiser4]
>  [<e0c7f97d>] reiser4_exit_context+0x1c2/0x571 [reiser4]
>  [<e0cbb091>] create_vfs_object+0x6ef/0x732 [reiser4]
>  [<e0cbb1fd>] mkdir_common+0x43/0x4b [reiser4]
>  [<c015ed33>] vfs_mkdir+0x5a/0x9d
>  [<c0160f5e>] sys_mkdirat+0x88/0xc0
>  [<c0160fa6>] sys_mkdir+0x10/0x12
>  [<c0102c2d>] sysenter_past_esp+0x56/0x8d
>
> (Linux antares.localdomain 2.6.18-rc2-mm1 #77 Sun Jul 30 15:09:34
> CEST 2006 i686 AMD Athlon(TM) XP 1600+ unknown GNU/Linux)

-- 
Alex.