Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/sys/kern



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: david%l8s.co.uk@localhost


Home | Main Index | Thread Index | Old Index