lkml.org 
[lkml]   [2012]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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...



\
 
 \ /
  Last update: 2012-07-31 12:21    [W:0.127 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site