From: Jeff Layton <jlayton@redhat.com>
To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: ebiederm@xmission.com, pavel@ucw.cz, miklos@szeredi.hu,
viro@ZenIV.linux.org.uk
Subject: [PATCH 1/3] vfs: force reval of target when following LAST_BIND symlinks
Date: Mon, 23 Nov 2009 12:41:22 -0500 [thread overview]
Message-ID: <1258998084-26797-2-git-send-email-jlayton@redhat.com> (raw)
In-Reply-To: <1258998084-26797-1-git-send-email-jlayton@redhat.com>
procfs-style symlinks return a last_type of LAST_BIND without an actual
path string. This causes __follow_link to skip calling __vfs_follow_link
and so the dentry isn't revalidated.
This is a problem when the link target sits on NFSv4 as it depends on
the VFS to revalidate the dentry before using it on an open call. Ensure
that this occurs by forcing a revalidation of the target dentry of
LAST_BIND symlinks.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
---
fs/namei.c | 40 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index 3374917..2c10519 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -414,6 +414,44 @@ do_revalidate(struct dentry *dentry, struct nameidata *nd)
}
/*
+ * force_reval_path - force revalidation of a dentry
+ *
+ * In some situations the path walking code will trust dentries without
+ * revalidating them. This causes problems for filesystems that depend on
+ * d_revalidate to handle file opens (e.g. NFSv4). When FS_REVAL_DOT is set
+ * (which indicates that it's possible for the dentry to go stale), force
+ * a d_revalidate call before proceeding.
+ *
+ * Returns 0 if the revalidation was successful. If the revalidation fails,
+ * either return the error returned by d_revalidate or -ESTALE if the
+ * revalidation it just returned 0. On error, references to the path are put.
+ * Note that on error, the dentry is not d_invalidated. If the VFS is assuming
+ * that the dentry is valid, then invalidating it could have adverse effects
+ * elsewhere.
+ */
+static int
+force_reval_path(struct path *path, struct nameidata *nd)
+{
+ int status;
+ struct dentry *dentry = path->dentry;
+
+ /*
+ * only check on filesystems where it's possible for the dentry to
+ * become stale. It's assumed that if this flag is set then the
+ * d_revalidate op will also be defined.
+ */
+ if (!(dentry->d_sb->s_type->fs_flags & FS_REVAL_DOT))
+ return 0;
+
+ status = dentry->d_op->d_revalidate(dentry, nd);
+ if (status > 0)
+ return 0;
+
+ path_put(path);
+ return status ? status : -ESTALE;
+}
+
+/*
* Internal lookup() using the new generic dcache.
* SMP-safe
*/
@@ -641,6 +679,8 @@ static __always_inline int __do_follow_link(struct path *path, struct nameidata
error = 0;
if (s)
error = __vfs_follow_link(nd, s);
+ else if (nd->last_type == LAST_BIND)
+ error = force_reval_path(&nd->path, nd);
if (dentry->d_inode->i_op->put_link)
dentry->d_inode->i_op->put_link(dentry, nd, cookie);
}
--
1.5.5.6
next prev parent reply other threads:[~2009-11-23 17:41 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-23 17:41 [PATCH 0/3] vfs: plug some holes involving LAST_BIND symlinks and file bind mounts (try #5) Jeff Layton
2009-11-23 17:41 ` Jeff Layton [this message]
2009-11-23 17:41 ` [PATCH 2/3] vfs: force reval on dentry of bind mounted files on FS_REVAL_DOT filesystems Jeff Layton
2009-11-23 17:41 ` [PATCH 3/3] vfs: check path permissions on target of LAST_BIND symlinks Jeff Layton
2009-11-23 22:05 ` [PATCH 0/3] vfs: plug some holes involving LAST_BIND symlinks and file bind mounts (try #5) Eric W. Biederman
2009-11-23 22:36 ` Jeff Layton
2009-11-23 22:49 ` Jamie Lokier
2009-11-23 23:15 ` Jeff Layton
2009-11-23 23:35 ` Eric W. Biederman
2009-11-24 0:34 ` Jeff Layton
2009-11-24 1:20 ` Jamie Lokier
2009-11-24 11:26 ` Jeff Layton
2009-11-24 11:53 ` Miklos Szeredi
2009-11-24 12:09 ` Pavel Machek
2009-11-24 12:59 ` Miklos Szeredi
2009-11-30 12:28 ` Pavel Machek
2009-11-30 19:21 ` Eric W. Biederman
2009-11-24 13:13 ` Duane Griffin
2009-11-30 19:00 ` Jamie Lokier
2009-12-01 8:56 ` Duane Griffin
2009-12-16 12:31 ` Al Viro
2009-12-20 19:59 ` Pavel Machek
2009-12-20 21:04 ` Al Viro
2009-12-20 21:06 ` Pavel Machek
2009-12-20 21:23 ` Al Viro
2010-01-01 15:40 ` Pavel Machek
2010-01-10 4:42 ` Al Viro
2009-12-01 13:15 ` Jeff Layton
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=1258998084-26797-2-git-send-email-jlayton@redhat.com \
--to=jlayton@redhat.com \
--cc=ebiederm@xmission.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=pavel@ucw.cz \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).