> Alexander Viro <viro@math.psu.edu> wrote:
> > Sorry, I didn't realize what you were asking for. Comments re POSIX are
> > correct, but in that case everything is much worse. What kind of
> > semantics do you want here? Two dentries for the object at the same
> > moment? Sorry, no.
>
> Why should this be required?
>
> How about:
>
> mark directory busy
> unhash dentry
> change dentry
To what? The whole bloody problem being: target dentry (which
is all that represents the new name) ought to be different from the
source one. Otherwise you've already forgotten the new name. Fine, but we
can't allow it to be positive and hashed. Otherwise we will end up
*deep* in it. So we need it unhashed. I.e. rename() (VFS one) can't use
regular lookup_dentry() for target. Great. But case of mv foo Foo is not
the only losing one: consider touch foo; mv bar Foo;. foo must die - this
misbegotten filesystem doesn't allow foo and Foo simultaneously. OK. So
target dentry should be over the inode of foo, but with the name Foo. Same
problem, right? That is, on the last step of target lookup we need
(a) different dentry comparison and (b) non-hashing ->lookup(). And we
have to deal with the possibility of *anything* happening to namespace
while we are trying to obtain the locks on directories. That thing is
badly handled by the current namei.c. Witness the check_parent() kludge
and stuff around its calls. You don't need much to get a really bad race
here - more than enough material is already in place. "Bad" as in "once
you've got it you can easily drive the thing into deadlock/fs corruption".
That's the real place to be fixed.
-
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/