lkml.org 
[lkml]   [2001]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] cleanup for fixing get_super() races


    On Fri, 27 Apr 2001, Linus Torvalds wrote:

    > On Fri, 27 Apr 2001, Alexander Viro wrote:
    > >
    > > Each of these places is an oopsable race with umount. We can't fix them
    > > without touching a lot of drivers. However, we can make the future fix
    > > easier if we put the above into a helper function. Patch below does that.
    >
    > I don't like the name "ream_inodes()".
    >
    > Also, a driver shouldn't know about "inodes" and "buffers". It should just
    > do something like
    >
    > invalidate_device(dev);
    >
    > because the only thing the driver knows about is the _device_.
    >
    > Then, invalidate_device() might do
    >
    > sb = get_super(dev)
    > if (sb)
    > invalidate_inodes (sb);
    > invalidate_buffers(dev);
    >
    > which makes some amount of sense. And which can later be extended to deal
    > with the page cache etc without the drivers ever knowing or caring.

    Fine with me. Actually in _all_ cases execept cdrom.c it's preceded by
    either sync_dev() or fsync_dev(). What do you think about pulling that
    into the same function? Actually, that's what I've done in namespace
    patch (name being invalidate_dev(), BTW ;-) The only problem I see
    here is the argument telling whether we want sync or fsync (or nothing).
    OTOH, I seriously suspect that we ought replace all sync_dev() cases
    with fsync_dev() anyway... Your opinion?
    Al

    -
    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-03-22 12:52    [W:6.524 / U:0.056 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site