From: Ian Kent <raven@themaw.net>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Brian Foster <bfoster@redhat.com>,
"Darrick J. Wong" <djwong@kernel.org>,
Christoph Hellwig <hch@lst.de>,
Miklos Szeredi <miklos@szeredi.hu>,
David Howells <dhowells@redhat.com>,
Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
xfs <linux-xfs@vger.kernel.org>
Subject: [PATCH] vfs: check dentry is still valid in get_link()
Date: Mon, 10 Jan 2022 17:11:31 +0800 [thread overview]
Message-ID: <164180589176.86426.501271559065590169.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 1f9d2187c765..37a7dba3083b 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:[~2022-01-10 9:20 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-10 9:11 Ian Kent [this message]
2022-01-15 6:38 ` [PATCH] vfs: check dentry is still valid in get_link() Al Viro
2022-01-17 2:55 ` Ian Kent
2022-01-17 14:35 ` Brian Foster
2022-01-17 16:28 ` Al Viro
2022-01-17 18:10 ` Al Viro
2022-01-17 19:48 ` Al Viro
2022-01-18 1:32 ` Al Viro
2022-01-18 2:31 ` Ian Kent
2022-01-18 3:03 ` Al Viro
2022-01-18 13:47 ` Brian Foster
2022-01-18 18:25 ` Brian Foster
2022-01-18 19:20 ` Al Viro
2022-01-18 20:58 ` Brian Foster
2022-01-18 8:29 ` Christian Brauner
2022-01-18 16:04 ` Al Viro
2022-01-19 9:05 ` Christian Brauner
2022-01-17 18:42 ` Brian Foster
2022-01-18 3:00 ` Dave Chinner
2022-01-18 3:17 ` Al Viro
2022-01-18 4:12 ` Dave Chinner
2022-01-18 5:58 ` Al Viro
2022-01-18 23:25 ` Dave Chinner
2022-01-19 14:08 ` Brian Foster
2022-01-19 22:07 ` Dave Chinner
2022-01-20 16:03 ` Brian Foster
2022-01-20 16:34 ` Brian Foster
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=164180589176.86426.501271559065590169.stgit@mickey.themaw.net \
--to=raven@themaw.net \
--cc=bfoster@redhat.com \
--cc=dhowells@redhat.com \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--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.