Re: [vfs:for-next] mnt_want_write: possible circular locking dependency detected

[Al Viro <viro@ZenIV.linux.org.uk>]

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