On Fri, Oct 19, 2012 at 07:58:34AM +0100, David Laight wrote:
> > Module Name: src
> > Committed By: riastradh
> > Date: Fri Oct 19 02:07:23 UTC 2012
> >
> > Modified Files:
> > src/sys/kern: vfs_syscalls.c
> >
> > Log Message:
> > No, we can't elide the fs-wide rename lock for same-directory rename.
> >
> > rename("a/b", "a/c") and rename("a/c/x", "a/b/y") will deadlock.
>
> Surely it just converts rename("a/c/x", "a/b/y") into
> rename("a/c/x", "a/c/y") which isn't quite the intended operation.
No, it will (or can) deadlock. The problem is that for the second
(cross-directory) rename, as far as it can tell a/c and a/b are
incommensurate, so it locks in an arbtrary order (which for
reasons of internal convenience is a/b first then a/c) but the
same-dir rename locks a/b first then a/c.
> Maybe convert the fs-wide rename lock into a rw-lock and only require
> read access for a same-directory rename.
That will not help.
> That might only be useful in the common case where the two directory
> paths are the same actual character - when only one VOP_LOOKUP()
> is needed at all and the child inodes don't even need looking at.
...?
> I suspect the DNLC (and any other caches) will need both rename ops done
> atomically though.
That's not the issue.
--
David A. Holland
dholl...@netbsd.org
