lkml.org 
[lkml]   [2005]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] fix nr_unused accounting, and avoid recursing in iput with I_WILL_FREE set
    On Tue, Oct 18, 2005 at 07:26:46PM -0700, Andrew Morton wrote:
    > Chris Mason <mason@suse.com> wrote:
    > >
    > > On Tue, Oct 18, 2005 at 06:15:48PM -0700, Andrew Morton wrote:
    > > > > > Well according to my assertion (below), the inode in __sync_single_inode()
    > > > > > cannot have a zero refcount, so the whole if() statement is never executed.
    > > > >
    > > > > generic_forget_inode->write_inode_now->__writeback_single_inode->
    > > > > __sync_single_inode
    > > >
    > > > oshit.
    > >
    > > When does this ever happen? Just for private inodes released during
    > > put_super right?
    >
    > I suppose so, yes.

    It's not related to the bug, but prune_icache can jump in at any
    time during generic_shutdown_super, except during the invalidate_inodes
    runs. Something like this:

    proc1 proc2
    generic_shutdown_super
    s->s_flags &= ~MS_ACTIVE
    invalidate_inodes
    put_super
    shrink_icache_memory
    prune_icache
    invalidate_inode_pages
    try_to_release_page

    I doubt any FS triggers this. They would need to generate inodes
    with pages during the put_super call, and get them onto the unused list.
    But, I think prune_icache should just skip any inodes where the super
    doesn't have MS_ACTIVE set.

    At any rate, this wasn't the race I was looking for. Aside from the
    bugs fixed by Andrea's patch, we were seeing inodes go negative thanks
    to a bad interaction between a latency fix and a backport of something
    else from mainline. Our latency code has a goto again, and mainline
    has a big fat comment explaining why goto again isn't needed.

    If the super->s_inodes list was long enough to reschedule in invalidate_list,
    we would process the same inodes in multiple times without removing them.

    The short version is that no additional patches should be needed for
    mainline.

    -chris

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-10-25 04:27    [W:0.027 / U:179.332 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site