[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1340996280-27123-15-git-send-email-jlayton@redhat.com>
Date: Fri, 29 Jun 2012 14:57:57 -0400
From: Jeff Layton <jlayton@...hat.com>
To: viro@...IV.linux.org.uk
Cc: linux-fsdevel@...r.kernel.org, linux-nfs@...r.kernel.org,
linux-kernel@...r.kernel.org, michael.brantley@...haw.com,
hch@...radead.org, miklos@...redi.hu, pstaubach@...grid.com
Subject: [PATCH v3 14/17] vfs: fix renameat to retry on ESTALE errors
...as always, rename is the messiest of the bunch. We have to track
whether to retry or not via a separate flag since the error handling
is already quite complex.
Signed-off-by: Jeff Layton <jlayton@...hat.com>
---
fs/namei.c | 31 ++++++++++++++++++++++++++-----
1 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index 7fadc99..b38d734 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -3392,12 +3392,25 @@ SYSCALL_DEFINE4(renameat, int, olddfd, const char __user *, oldname,
char *from;
char *to;
int error;
+ unsigned int try = 0;
+ bool should_retry = false;
+ unsigned int lookup_flags = LOOKUP_PARENT;
- error = user_path_parent(olddfd, oldname, &oldnd, &from);
- if (error)
+ from = getname(oldname);
+ if (IS_ERR(from))
+ return PTR_ERR(from);
+
+ to = getname(newname);
+ if (IS_ERR(to)) {
+ error = PTR_ERR(to);
goto exit;
+ }
+retry:
+ error = do_path_lookup(olddfd, from, lookup_flags, &oldnd);
+ if (error)
+ goto exit0;
- error = user_path_parent(newdfd, newname, &newnd, &to);
+ error = do_path_lookup(newdfd, to, lookup_flags, &newnd);
if (error)
goto exit1;
@@ -3466,13 +3479,21 @@ exit4:
dput(old_dentry);
exit3:
unlock_rename(new_dir, old_dir);
+ if (retry_estale(error, try++))
+ should_retry = true;
exit2:
path_put(&newnd.path);
- putname(to);
exit1:
path_put(&oldnd.path);
- putname(from);
+ if (should_retry) {
+ should_retry = false;
+ lookup_flags |= LOOKUP_REVAL;
+ goto retry;
+ }
+exit0:
+ putname(to);
exit:
+ putname(from);
return error;
}
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists