Re: patch for fs/dcache race

Linus Torvalds (torvalds@transmeta.com)
Sun, 10 Aug 1997 11:36:22 -0700 (PDT)


On Sun, 10 Aug 1997, Bill Hawes wrote:
>
> > I guess I should rewrite d_move() to be more robust: there really isn't
> > any reason for the stale parent pointer in the first place. (And while I
> > don't think this is a bug, I certainly agree that it is very ugly).
>
> I would like to see the new name allocation removed -- the new name
> should be allocated by the client, so that the potential error can be
> reported. Then if the new name is passed in as a reference to a dentry,
> d_move can just steal the new name and swap the old name.

I've done this now as part of the re-write. That also turned up a _real_
bug. The old code used to do:

d_move(dentry, new-locaction);
d_delete(new-location);

which _looks_ ok most of the time, but what actually can (and does) end up
happening is that new-location turns into a negative dentry. So now we
have a negative dentry with the same name and hash value as the dentry we
just created. The thing that hid this was just pure luck, the negative
dentry was generally short-lived and hidden by the newly done dentry.

The new code I have doesn't have this problem, and is a lot simpler. The
only problem with my current code is that it essentially "switches" names
from one dentry to the other. This is fine, and it performs very well
indeed (no new allocations needed, and even the parents don't need to have
their counts updated because we switch parents too). However, it does mean
that iof anybody had the old (now deleted) file open, the file will show
up with the wrong name in /proc.

That's only a minor beauty wart, though - the file has been deleted so it
really doesn't have any name at all in a sense. But it would be nicer if
we'd show the old name just before it got deleted, rather than the name
that forced it to be deleted due to the rename()..

Linus