I wasn't so concerned with the case for a deleted file, but rather for
the case where the rename target doesn't yet exist. Because of the
numerous blocking operations involved with a rename, there are races
that might allow a new dentry to be linked to the rename target -- a
file contained in a directory, for example.
The operation couldn't get very far before being stopped by a directory
semaphore, but it might be far enough so that the operation would
complete successfully but leave the new dentry linked to the now
name-swapped target. The current locking at the fs level doesn't stop
things from happening at the dentry level.
It seems like you might need locking at the dentry level to prevent this
-- the equivalent of the directory semaphore.
This potential problem is really separate from the name-swapping
implementation, so it doesn't affect the decision of how to implement
d_move.
But I guess I marginally prefer to name-swap with an unused dentry
allocated for just that purpose, as it avoids even the minor issue of an
in-use file with the wrong name.
Regards,
Bill