Messages in this thread | | | Date | Fri, 15 Jan 1999 02:09:59 -0500 (EST) | From | Alexander Viro <> | Subject | Re: [PATCH] VFAT fixes. |
| |
On Thu, 14 Jan 1999, Linus Torvalds wrote:
> > > On Thu, 14 Jan 1999, Alexander Viro wrote: > > > > c) trivial patch to d_move() making sure that after a move we'll get > > hashed dentry, even if target was unhashed (another race). > > I think this is just evil, and should never be allowed. > > This code is just an excuse to let other bugs abound. If we use d_move(), > we should have made certain that both parents were locked. If that part of > your patch fixes anything, something else is wrong.
Nope. Sorry, I should have explain it better. If we are renaming over the directory we should unhash the target at least for the time between the beginning of emptiness check and the moment when we cannibalize the target. Otherwise we are open for races (somebody could grab the target and make it non-empty). d_move() is called only from rename() and since (a) all d_drops are protected by semaphore on the parent and (b) we would cry foul if somebody tried to pass unhashed dentry there we are OK. Bugs would be caught in vfs_rename(). Now, if I missed a place where (a) would not be true we are in much bigger trouble. It will screw a lot of places, not only rename(). Now, we could lock the target along with both parents, but I don't like the perspective of triple_lock() somewhere in namei.c. Up to you, indeed, but it seems to me that it's the only alternative.
Al
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |