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 09:33:03AM +0100, David Laight wrote:
> > > > 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.
No. And stop calling me Shirley. :-p
If they're directories, it has to update the ".." entry of the source
dir and truncate the target dir, both of which operations definitely
require locking. You can't tell if they're directories without looking
them up, which currently involves locking them. Even if they aren't
directories, you still need to unlink and maybe thereby truncate the
target file, and many file systems, including e.g. ffs, need to
manipulate the link count of the source file as well. This too
requires locking.
--
David A. Holland
dholland%netbsd.org@localhost
Home |
Main Index |
Thread Index |
Old Index