[lkml]   [2010]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 16/21] fs: Protect inode->i_state with the inode->i_lock
    On Fri, Oct 22, 2010 at 11:37:05AM +0100, Al Viro wrote:

    > What I'm going to do is to put together a branch with essentially cleanups
    > and trivial fixes, with both patchsets forked off its tip. Then move stuff
    > to common stem, rediffing the branches as we go. Then see what's left.

    OK, the current (partial) set is in #merge-stem

    What remains to be done (I'm about to fall down right now, so that'll have
    to wait until tomorrow):

    * writeback_sb_inode() told to ignore I_FREEING ones in addition to
    I_NEW and I_WILL_FREE ones it ignores now. Currently I_FREEING can't be
    found there at all, so that'll change nothing.
    * invalidate_inodes() - collect I_FREEING/I_WILL_FREE on a separate
    list, then (after we'd evicted the stuff we'd decided to evict) wait until
    they get freed by whatever's freeing them already.
    * remove_dquot_ref() - looks like we might be OK with that one being
    as it is - it walks sb list of inodes and for things like prune_icache()
    the inodes stay on said list all the way through evict(), so it either
    doesn't care or it's already broken. And no, I'm not discounting either
    possibility - it needs further analysis.

    That's it - after that we'll be OK with dropping and regaining inode_lock
    between the moment when we set I_FREEING and removals from the lists.

     \ /
      Last update: 2010-10-23 23:41    [W:0.020 / U:40.192 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site