lkml.org 
[lkml]   [1999]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.097 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site