I'll remove the unneeded locks. :-)
Jeff
Alexander Viro wrote:
>
> On Fri, 12 May 2000, Manfred Spraul wrote:
>
> > From: "Alexander Viro" <aviro@redhat.com>
> > > >
> > > > ->i_sem ->i_zombie
> > > > yes no lookup()
> > > > yes yes readdir(),create(),mknod(),mkdir(),symlink()
> >
> > Al, could you explain why readdir acquires i_zombie? It only reads from the
> > directory, it should be similar to lookup().
>
> Check for directory being already removed. All additional exclusion it
> gives (== all potential contention) is readdir(foo) vs rmdir(foo) and
> readdir(foo) vs rename over foo. But it gives us an easy way to catch
> removed-but-still-busy directories in VFS - the only operation you
> have to care about is ->lookup() (->i_zombie protects all directory
> removals, so VFS can seriously cut on the crap that is actually passed
> to filesystems).
>
> And unlike the ->readdir() ->lookup() couldn't care less for "." and ".." -
> the only SOB that calls it for any of those is nfsfh.c and it's on the way to
> extinction^Wrewrite. So for ->readdir() on removed directory you'ld have to
> special-case the things. For ->lookup() you normally don't have to.
>
> Notice that almost all filesystems can handle removed-but-still-busy
> directories - both for rmdir() and rename(). No -EBUSY for you, no special-case
> code...
>
> > > Another thing is that directory-moving rename()s within the same
> > filesystem
> > > are serialized (different filesystems are independent, indeed).
> > >
> > AFAIKS it should be possible to reorder
> >
> > down(&s_vfs_rename_sem);
> > is_subdir()
> > triple_down(...)
> >
> > to
> > triple_down();
> > down(&s_vfs_rename_sem);
> > is_subdir();
> >
> > [I'm sure there is a problem, but I don't see it]
> > s_vfs_rename_sem is the global semaphore, we should try to hold is as short
> > as possible.
>
> Should we? Think what is needed to get a contention on triple_down()[1] - keep
> in mind that ->i_sem on both parents had been already taken. It's actually
> stopping the pathological cases, not holding the contenders back.
>
> [1] Arrgh. OK, now namei.c looks almost tolerable wrt races - the last bunch
> was between rename() and unlink() and they were squashed in April when
> LOOKUP_PARENT went in. But damnit, triple_down() is PITA. I would appreciate
> folks looking through the implementation, BTW - I _think_ that it's OK, but...
> New namespace-modifiers look more or less simple - get parent(s) and hash(es)
> of last component(s), lock parent(s) (->i_sem), do lookup(s) on last
> component(s), down ->i_zombie where needed, check for dead directories and
> other common rules on removal/adding links (sticky bits, permissions,
> append-only, etc.), do the thing, unlock and release everything.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:21 EST