Re: CVS commit: src/sys/kern

[David Holland <dholland-sourcechanges%netbsd.org@localhost>]

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
dholland%netbsd.org@localhost