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/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:21 EST