On Sat, Oct 20, 2012 at 04:06:13AM +0000, David Holland wrote: > 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.
Why does the same-dir rename need to lock either a/b or a/c ? Surely it is just an operation on the 'file' contents of a itself. Clearly that can only be done if you detect the same-dir-ness of the rename by analysing the filename paths, but that is likely the common case. David -- David Laight: da...@l8s.co.uk