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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
