From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [vfs:for-next] mnt_want_write: possible circular locking dependency detected Date: Tue, 31 Jul 2012 10:41:21 +0100 Message-ID: <20120731094121.GG6481@ZenIV.linux.org.uk> References: <20120731082943.GB14475@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kara , linux-fsdevel@vger.kernel.org, LKML To: Fengguang Wu Return-path: Content-Disposition: inline In-Reply-To: <20120731082943.GB14475@localhost> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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...