From: Ian Kent <raven@themaw.net>
To: xfs <linux-xfs@vger.kernel.org>, "Darrick J. Wong" <djwong@kernel.org>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
Brian Foster <bfoster@redhat.com>,
Al Viro <viro@ZenIV.linux.org.uk>,
David Howells <dhowells@redhat.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: [PATCH 1/2] vfs: check dentry is still valid in get_link()
Date: Thu, 11 Nov 2021 11:39:19 +0800 [thread overview]
Message-ID: <163660195990.22525.6041281669106537689.stgit@mickey.themaw.net> (raw)
When following a trailing symlink in rcu-walk mode it's possible for
the dentry to become invalid between the last dentry seq lock check
and getting the link (eg. an unlink) leading to a backtrace similar
to this:
crash> bt
PID: 10964 TASK: ffff951c8aa92f80 CPU: 3 COMMAND: "TaniumCX"
…
#7 [ffffae44d0a6fbe0] page_fault at ffffffff8d6010fe
[exception RIP: unknown or invalid address]
RIP: 0000000000000000 RSP: ffffae44d0a6fc90 RFLAGS: 00010246
RAX: ffffffff8da3cc80 RBX: ffffae44d0a6fd30 RCX: 0000000000000000
RDX: ffffae44d0a6fd98 RSI: ffff951aa9af3008 RDI: 0000000000000000
RBP: 0000000000000000 R8: ffffae44d0a6fb94 R9: 0000000000000000
R10: ffff951c95d8c318 R11: 0000000000080000 R12: ffffae44d0a6fd98
R13: ffff951aa9af3008 R14: ffff951c8c9eb840 R15: 0000000000000000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#8 [ffffae44d0a6fc90] trailing_symlink at ffffffff8cf24e61
#9 [ffffae44d0a6fcc8] path_lookupat at ffffffff8cf261d1
#10 [ffffae44d0a6fd28] filename_lookup at ffffffff8cf2a700
#11 [ffffae44d0a6fe40] vfs_statx at ffffffff8cf1dbc4
#12 [ffffae44d0a6fe98] __do_sys_newstat at ffffffff8cf1e1f9
#13 [ffffae44d0a6ff38] do_syscall_64 at ffffffff8cc0420b
Most of the time this is not a problem because the inode is unchanged
while the rcu read lock is held.
But xfs can re-use inodes which can result in the inode ->get_link()
method becoming invalid (or NULL).
This case needs to be checked for in fs/namei.c:get_link() and if
detected the walk re-started.
Signed-off-by: Ian Kent <raven@themaw.net>
---
fs/namei.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/namei.c b/fs/namei.c
index 1946d9667790..9a48a6106516 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1760,8 +1760,11 @@ static const char *pick_link(struct nameidata *nd, struct path *link,
if (!res) {
const char * (*get)(struct dentry *, struct inode *,
struct delayed_call *);
- get = inode->i_op->get_link;
+ get = READ_ONCE(inode->i_op->get_link);
if (nd->flags & LOOKUP_RCU) {
+ /* Does the inode still match the associated dentry? */
+ if (unlikely(read_seqcount_retry(&link->dentry->d_seq, last->seq)))
+ return ERR_PTR(-ECHILD);
res = get(NULL, inode, &last->done);
if (res == ERR_PTR(-ECHILD) && try_to_unlazy(nd))
res = get(link->dentry, inode, &last->done);
next reply other threads:[~2021-11-11 3:39 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-11 3:39 Ian Kent [this message]
2021-11-11 3:39 ` [PATCH 2/2] xfs: make sure link path does not go away at access Ian Kent
2021-11-11 16:08 ` Brian Foster
2021-11-11 23:10 ` Ian Kent
2021-11-12 11:47 ` Brian Foster
2021-11-13 5:17 ` Ian Kent
2021-11-12 0:32 ` Dave Chinner
2021-11-12 1:26 ` Ian Kent
2021-11-12 7:23 ` Miklos Szeredi
2021-11-14 23:18 ` Dave Chinner
2021-11-15 9:21 ` Miklos Szeredi
2021-11-15 22:24 ` Dave Chinner
2021-11-16 1:03 ` Ian Kent
2021-11-16 3:01 ` Dave Chinner
2021-11-16 10:12 ` Miklos Szeredi
2021-11-16 16:04 ` Brian Foster
2021-11-16 13:38 ` Ian Kent
2021-11-16 15:59 ` Brian Foster
2021-11-17 0:22 ` Dave Chinner
2021-11-17 2:19 ` Ian Kent
2021-11-17 21:06 ` Dave Chinner
2021-11-17 18:56 ` Brian Foster
2021-11-17 21:48 ` Dave Chinner
2021-11-19 19:44 ` Brian Foster
2021-11-22 0:08 ` Dave Chinner
2021-11-22 19:27 ` Brian Foster
2021-11-22 23:26 ` Dave Chinner
2021-11-24 20:56 ` Brian Foster
2021-12-15 3:54 ` Ian Kent
2021-12-15 5:06 ` Darrick J. Wong
2021-12-16 2:45 ` Ian Kent
2021-11-17 20:38 ` kernel test robot
2021-11-17 20:38 ` kernel test robot
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=163660195990.22525.6041281669106537689.stgit@mickey.themaw.net \
--to=raven@themaw.net \
--cc=bfoster@redhat.com \
--cc=dhowells@redhat.com \
--cc=djwong@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--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.