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, 07 Nov 2011 18:18:27 +0100
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Knut Petersen <Knut_Petersen@...nline.de>,
	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>,
	Jeff Mahoney <jeffm@...e.com>
Subject: Re: [BUG] kernel 3.1.0 possible circular locking dependency detected

On Mon, 2011-10-31 at 08:08 -0700, Linus Torvalds wrote:
> [ 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?

I_MUTEX_XATTR sounds like the right nesting for something called
xattr_*() but then, what do I know about filesystems.. Jeff Mahoney
wrote this, Jeff any clue?
--
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/