Re: [BUG] kernel 3.1.0 possible circular locking dependency detected

From: Linus Torvalds
Date: Mon Oct 31 2011 - 11:09:18 EST

[ Added a few more people to the cc ]

On Mon, Oct 31, 2011 at 1:35 AM, Knut Petersen
<Knut_Petersen@xxxxxxxxxxx> wrote:
> After a " rm -r /verybigdir" (about 12G on a 25G reiserfs 3.6partition)
> I found the following report about a circular locking dependency in
> kernel 3.1.0

Heh. There is even a comment about the ordering violation:

/* We use I_MUTEX_CHILD here to silence lockdep. It's safe because xattr
* mutation ops aren't called during rename or splace, which are the
* only other users of I_MUTEX_CHILD. It violates the ordering, but that's
* better than allocating another subclass just for this code. */

and apparently the comment is wrong: we *do* end up looking up xattrs
during splice, due to the security_inode_need_killpriv() thing.

So I think this needs a suid (or sgid) file that has xattrs and is removed.

That said, I suspect this is a false positive, because the actual
unlink can never happen while somebody is splicing to/from the same
file at the same time (because then the iput wouldn't be the last one
for the inode, and the file removal would be delayed until the file
has been closed for the last time).

But the hacky use of "I_MUTEX_CHILD" is basically not the proper way
to silence the lockdep splat.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at