Re: 2.6.21 reiserfs -- cicular locking?

[Jeff Mahoney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Takashi Iwai wrote:
> At Fri, 27 Apr 2007 07:09:01 -0400,
> Jeff Mahoney wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Takashi Iwai wrote:
>>> At Fri, 27 Apr 2007 12:09:03 +0200,
>>> I wrote:
>>>> I got a similar bug right now at the fresh boot of 2.6.21.
>>>>
>>>>
>>>> ReiserFS: sda2: found reiserfs format "3.6" with standard journal
>>>> ReiserFS: sda2: using ordered data mode
>>>> ReiserFS: sda2: journal params: device sda2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
>>>> ReiserFS: sda2: checking transaction log (sda2)
>>>> ReiserFS: sda2: Using r5 hash to sort names
>>>> ReiserFS: sda2: Removing [3613 1354701 0x0 SD]..done
>>>> ReiserFS: sda2: There were 1 uncompleted unlinks/truncates. Completed
>>>>
>>>> =======================================================
>>>> [ INFO: possible circular locking dependency detected ]
>>>> 2.6.21-work #1
>>>> -------------------------------------------------------
>>>> mktemp/1459 is trying to acquire lock:
>>>>  (&REISERFS_I(inode)->xattr_sem){..--}, at: [<e08a5236>] reiserfs_cache_default_acl+0x2a/0x9c [reiserfs]
>>>>
>>>> but task is already holding lock:
>>>>  (&inode->i_mutex){--..}, at: [<c016d7dc>] open_namei+0xe2/0x5a2
>>>>
>>>> which lock already depends on the new lock.
>>> The message disappears when I revert the patch:
>>>
>>> commit 9b7f375505f5611efb562065b57814b28a81abc3
>>> Author: Jeff Mahoney <jeffm@xxxxxxxx>
>>> Date:   Mon Apr 23 14:41:17 2007 -0700
>>>
>>>     reiserfs: fix xattr root locking/refcount bug
>>>     
>>>
>>> So, likely a newly introduced bug after rc7...
>> I got a message with a trace similar to this from Vladimir before I
>> submitted that patch. I'm not sure how to annotate this, since the
>> xattr_sem can never be taken in the manner described. Internal inodes
>> are protected by I_PRIVATE.
> 
> Hm, then maybe my case was just a coincidence.
> 
> FWIW, I can reproduce the deadlock warning at each time I boot
> non-patched 2.6.21, and after reverting the patch, it disappeared.

Ok, so I took another look at the report Vladimir sent me. The trace he
ran into was in the delete inode path, but was still a race between the
xattr_sem and the inode sem. Since we're locking the xattr root on the
xattr read path now, this condition arises more freqently, but it's
really the same one he reported.

I'm using the default openSUSE config, which doesn't enable mutex
debugging. I'll rebuild with it, and hopefully come up with a way to
kill the warning.

- -Jeff

- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGMhP8LPWxlyuTD7IRAiInAJwO7Tpga98WvcPICFMSyvb0vSAvrQCdEbal
XScT+lxIu181A6KNzKhNuYw=
=K/gK
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/