linux-kernel - Re: [vfs:for-next] mnt_want_write: 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 for Android: free password hash cracker in your pocket

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

Message-ID: <20120731094121.GG6481@ZenIV.linux.org.uk>
Date:	Tue, 31 Jul 2012 10:41:21 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Fengguang Wu <fengguang.wu@...el.com>
Cc:	Jan Kara <jack@...e.cz>, linux-fsdevel@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [vfs:for-next] mnt_want_write: possible circular locking
 dependency detected

On Tue, Jul 31, 2012 at 04:29:43PM +0800, Fengguang Wu wrote:
> Hi Jan,
> 
> I caught the following warning at this commit. Note that the head
> commit actually boots OK, so it may either be not 100% reproduciable,
> or get fixed somewhere in your patchset.

In the next commit, actually.  I'm still not sure about that one -
is "just ignore atime updates on frozen fs" the right approach?

AFAICS, the situation looks so:
	* most of the callers can't hold ->i_mutex
	* main exception is vfs_readdir(); it's not hard to pull that
file_accessed() outside of ->i_mutex there.  The same goes for one 
of the similar bits in coda.
	* another sucker in coda (coda_venus_readdir()) is essentially
a false positive - we are holding ->i_mutex on a directory inode
in coda, end up reading from a regular file on normal fs and update
its atime.  Hell knows; looks more like an annotation problem for me,
even though I'm not sure how to deal with it cleanly.
	* hugetlbfs_file_mmap() just needs file_accessed() moved one line
up.
	* xfs_file_splice_read() doesn't hold ->i_mutex, but it does
hold some XFS lock; might or might not be a problem
	* really ugly one - read request on /dev/loop update atime of
underlying file.  They might bloody well happen from pagefault path,
etc., potentially while doing write(2) into the same file and holding
->i_mutex on it.  Hell knows what's the rigth semantics here...

--
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/