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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 31 Oct 2011 08:08:55 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Knut Petersen <Knut_Petersen@...nline.de>
Cc:	linux-kernel@...r.kernel.org, reiserfs-devel@...r.kernel.org,
	Greg KH <gregkh@...e.de>, Al Viro <viro@...iv.linux.org.uk>,
	Christoph Hellwig <hch@....de>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [BUG] kernel 3.1.0 possible circular locking dependency detected

[ Added a few more people to the cc ]

On Mon, Oct 31, 2011 at 1:35 AM, Knut Petersen
<Knut_Petersen@...nline.de> 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.

Anybody?

                  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/