[lkml]   [2012]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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
    * 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.022 / U:5.648 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site