From: "J. Bruce Fields" <bfields@redhat.com>
To: linux-fsdevel@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>,
Al Viro <viro@ZenIV.linux.org.uk>,
linux-nfs@vger.kernel.org, "J. Bruce Fields" <bfields@redhat.com>
Subject: [PATCH 4/8] exportfs: stop retrying once we race with rename/remove
Date: Fri, 25 Oct 2013 16:30:01 -0400 [thread overview]
Message-ID: <1382733005-6006-5-git-send-email-bfields@redhat.com> (raw)
In-Reply-To: <1382733005-6006-1-git-send-email-bfields@redhat.com>
From: "J. Bruce Fields" <bfields@redhat.com>
There are two places here where we could race with a rename or remove:
- We could find the parent, but then be removed or renamed away
from that parent directory before finding our name in that
directory.
- We could find the parent, and find our name in that parent,
but then be renamed or removed before we look ourselves up by
that name in that parent.
In both cases the concurrent rename or remove will take care of
reconnecting the directory that we're currently examining. Our target
directory should then also be connected. Check this and clear
DISCONNECTED in these cases instead of looping around again.
Note: we *do* need to check that this actually happened if we want to be
robust in the face of corrupted filesystems: a corrupted filesystem
could just return a completely wrong parent, and we want to fail with an
error in that case before starting to clear DISCONNECTED on
non-DISCONNECTED filesystems.
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
---
fs/exportfs/expfs.c | 45 ++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 40 insertions(+), 5 deletions(-)
diff --git a/fs/exportfs/expfs.c b/fs/exportfs/expfs.c
index c65b748..6b5ddd5 100644
--- a/fs/exportfs/expfs.c
+++ b/fs/exportfs/expfs.c
@@ -90,6 +90,23 @@ find_disconnected_root(struct dentry *dentry)
return dentry;
}
+static bool dentry_connected(struct dentry *dentry)
+{
+ dget(dentry);
+ while (dentry->d_flags & DCACHE_DISCONNECTED) {
+ struct dentry *parent = dget_parent(dentry);
+
+ dput(dentry);
+ if (IS_ROOT(dentry)) {
+ dput(parent);
+ return false;
+ }
+ dentry = parent;
+ }
+ dput(dentry);
+ return true;
+}
+
static void clear_disconnected(struct dentry *dentry)
{
dget(dentry);
@@ -189,9 +206,9 @@ reconnect_path(struct vfsmount *mnt, struct dentry *target_dir, char *nbuf)
dput(pd);
if (err == -ENOENT)
/* some race between get_parent and
- * get_name? just try again
+ * get_name?
*/
- continue;
+ goto out_reconnected;
break;
}
dprintk("%s: found name: %s\n", __func__, nbuf);
@@ -211,12 +228,12 @@ reconnect_path(struct vfsmount *mnt, struct dentry *target_dir, char *nbuf)
* hopefully, npd == pd, though it isn't really
* a problem if it isn't
*/
+ dput(npd);
+ dput(ppd);
if (npd == pd)
noprogress = 0;
else
- printk("%s: npd != pd\n", __func__);
- dput(npd);
- dput(ppd);
+ goto out_reconnected;
if (IS_ROOT(pd)) {
/* something went wrong, we have to give up */
dput(pd);
@@ -234,6 +251,24 @@ reconnect_path(struct vfsmount *mnt, struct dentry *target_dir, char *nbuf)
}
return 0;
+out_reconnected:
+ /*
+ * Someone must have renamed our entry into another parent, in
+ * which case it has been reconnected by the rename.
+ *
+ * Or someone removed it entirely, in which case filehandle
+ * lookup will succeed but the directory is now IS_DEAD and
+ * subsequent operations on it will fail.
+ *
+ * Alternatively, maybe there was no race at all, and the
+ * filesystem is just corrupt and gave us a parent that doesn't
+ * actually contain any entry pointing to this inode. So,
+ * double check that this worked and return -ESTALE if not:
+ */
+ if (!dentry_connected(target_dir))
+ return -ESTALE;
+ clear_disconnected(target_dir);
+ return 0;
}
struct getdents_callback {
--
1.7.9.5
WARNING: multiple messages have this Message-ID (diff)
From: "J. Bruce Fields" <bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"J. Bruce Fields"
<bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: [PATCH 4/8] exportfs: stop retrying once we race with rename/remove
Date: Fri, 25 Oct 2013 16:30:01 -0400 [thread overview]
Message-ID: <1382733005-6006-5-git-send-email-bfields@redhat.com> (raw)
In-Reply-To: <1382733005-6006-1-git-send-email-bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
From: "J. Bruce Fields" <bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
There are two places here where we could race with a rename or remove:
- We could find the parent, but then be removed or renamed away
from that parent directory before finding our name in that
directory.
- We could find the parent, and find our name in that parent,
but then be renamed or removed before we look ourselves up by
that name in that parent.
In both cases the concurrent rename or remove will take care of
reconnecting the directory that we're currently examining. Our target
directory should then also be connected. Check this and clear
DISCONNECTED in these cases instead of looping around again.
Note: we *do* need to check that this actually happened if we want to be
robust in the face of corrupted filesystems: a corrupted filesystem
could just return a completely wrong parent, and we want to fail with an
error in that case before starting to clear DISCONNECTED on
non-DISCONNECTED filesystems.
Signed-off-by: J. Bruce Fields <bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
fs/exportfs/expfs.c | 45 ++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 40 insertions(+), 5 deletions(-)
diff --git a/fs/exportfs/expfs.c b/fs/exportfs/expfs.c
index c65b748..6b5ddd5 100644
--- a/fs/exportfs/expfs.c
+++ b/fs/exportfs/expfs.c
@@ -90,6 +90,23 @@ find_disconnected_root(struct dentry *dentry)
return dentry;
}
+static bool dentry_connected(struct dentry *dentry)
+{
+ dget(dentry);
+ while (dentry->d_flags & DCACHE_DISCONNECTED) {
+ struct dentry *parent = dget_parent(dentry);
+
+ dput(dentry);
+ if (IS_ROOT(dentry)) {
+ dput(parent);
+ return false;
+ }
+ dentry = parent;
+ }
+ dput(dentry);
+ return true;
+}
+
static void clear_disconnected(struct dentry *dentry)
{
dget(dentry);
@@ -189,9 +206,9 @@ reconnect_path(struct vfsmount *mnt, struct dentry *target_dir, char *nbuf)
dput(pd);
if (err == -ENOENT)
/* some race between get_parent and
- * get_name? just try again
+ * get_name?
*/
- continue;
+ goto out_reconnected;
break;
}
dprintk("%s: found name: %s\n", __func__, nbuf);
@@ -211,12 +228,12 @@ reconnect_path(struct vfsmount *mnt, struct dentry *target_dir, char *nbuf)
* hopefully, npd == pd, though it isn't really
* a problem if it isn't
*/
+ dput(npd);
+ dput(ppd);
if (npd == pd)
noprogress = 0;
else
- printk("%s: npd != pd\n", __func__);
- dput(npd);
- dput(ppd);
+ goto out_reconnected;
if (IS_ROOT(pd)) {
/* something went wrong, we have to give up */
dput(pd);
@@ -234,6 +251,24 @@ reconnect_path(struct vfsmount *mnt, struct dentry *target_dir, char *nbuf)
}
return 0;
+out_reconnected:
+ /*
+ * Someone must have renamed our entry into another parent, in
+ * which case it has been reconnected by the rename.
+ *
+ * Or someone removed it entirely, in which case filehandle
+ * lookup will succeed but the directory is now IS_DEAD and
+ * subsequent operations on it will fail.
+ *
+ * Alternatively, maybe there was no race at all, and the
+ * filesystem is just corrupt and gave us a parent that doesn't
+ * actually contain any entry pointing to this inode. So,
+ * double check that this worked and return -ESTALE if not:
+ */
+ if (!dentry_connected(target_dir))
+ return -ESTALE;
+ clear_disconnected(target_dir);
+ return 0;
}
struct getdents_callback {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2013-10-25 20:30 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-25 20:29 [PATCH 0/8] simplify reconnecting dentries looked up by filehandle (v2) J. Bruce Fields
2013-10-25 20:29 ` J. Bruce Fields
2013-10-25 20:29 ` [PATCH 1/8] exportfs: BUG_ON in crazy corner case J. Bruce Fields
2013-10-25 20:29 ` [PATCH 2/8] exportfs: more detailed comment for path_reconnect J. Bruce Fields
2013-10-25 20:29 ` J. Bruce Fields
2013-10-25 20:30 ` [PATCH 3/8] exportfs: clear DISCONNECTED on all parents sooner J. Bruce Fields
2013-10-25 20:30 ` J. Bruce Fields
2013-10-25 20:30 ` J. Bruce Fields [this message]
2013-10-25 20:30 ` [PATCH 4/8] exportfs: stop retrying once we race with rename/remove J. Bruce Fields
2013-10-27 7:04 ` NeilBrown
2013-10-27 7:04 ` NeilBrown
2013-10-28 8:53 ` Christoph Hellwig
2013-10-28 8:53 ` Christoph Hellwig
2013-10-28 15:08 ` J. Bruce Fields
2013-10-25 20:30 ` [PATCH 5/8] exportfs: eliminate unused "noprogress" counter J. Bruce Fields
2013-10-25 20:30 ` [PATCH 6/8] exportfs: move most of reconnect_path to helper function J. Bruce Fields
2013-10-25 20:30 ` [PATCH 7/8] exportfs: better variable name J. Bruce Fields
2013-10-25 20:30 ` J. Bruce Fields
2013-10-25 20:30 ` [PATCH 8/8] exportfs: fix quadratic behavior in filehandle lookup J. Bruce Fields
2013-10-30 16:10 ` [PATCH 0/8] simplify reconnecting dentries looked up by filehandle (v2) Christoph Hellwig
2013-10-30 16:10 ` Christoph Hellwig
2013-10-30 16:38 ` J. Bruce Fields
2013-10-30 16:38 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1382733005-6006-5-git-send-email-bfields@redhat.com \
--to=bfields@redhat.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.