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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
