ocfs2: manually d_move() during ocfs2_rename()
Make use of FS_RENAME_DOES_D_MOVE to avoid a race condition that can occur during ->rename() if we d_move() outside of the parent directory cluster locks, and another node discovers the new name (created during the rename) and unlinks it. d_move() will unconditionally rehash a dentry - which will leave stale data in the system. Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
This commit is contained in:
@@ -414,7 +414,7 @@ void ocfs2_dentry_move(struct dentry *dentry, struct dentry *target,
|
||||
* XXX: Is there any advantage to dropping the lock here?
|
||||
*/
|
||||
if (old_dir == new_dir)
|
||||
return;
|
||||
goto out_move;
|
||||
|
||||
ocfs2_dentry_lock_put(osb, dentry->d_fsdata);
|
||||
|
||||
@@ -423,6 +423,9 @@ void ocfs2_dentry_move(struct dentry *dentry, struct dentry *target,
|
||||
OCFS2_I(new_dir)->ip_blkno, 0);
|
||||
if (ret)
|
||||
mlog_errno(ret);
|
||||
|
||||
out_move:
|
||||
d_move(dentry, target);
|
||||
}
|
||||
|
||||
struct dentry_operations ocfs2_dentry_ops = {
|
||||
|
Reference in New Issue
Block a user