From: Miklos Szeredi <miklos@szeredi.hu>
To: Dave Chinner <david@fromorbit.com>
Cc: Ian Kent <raven@themaw.net>, xfs <linux-xfs@vger.kernel.org>,
"Darrick J. Wong" <djwong@kernel.org>,
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: Re: [PATCH 2/2] xfs: make sure link path does not go away at access
Date: Mon, 15 Nov 2021 10:21:03 +0100 [thread overview]
Message-ID: <CAJfpegu4BwJD1JKngsrzUs7h82cYDGpxv0R1om=WGhOOb6pZ2Q@mail.gmail.com> (raw)
In-Reply-To: <20211114231834.GM449541@dread.disaster.area>
On Mon, 15 Nov 2021 at 00:18, Dave Chinner <david@fromorbit.com> wrote:
> I just can't see how this race condition is XFS specific and why
> fixing it requires XFS to sepcifically handle it while we ignore
> similar theoretical issues in other filesystems...
It is XFS specific, because all other filesystems RCU free the in-core
inode after eviction.
XFS is the only one that reuses the in-core inode object and that is
very much different from anything the other filesystems do and what
the VFS expects.
I don't see how clearing the quick link buffer in ext4_evict_inode()
could do anything bad. The contents are irrelevant, the lookup will
be restarted anyway, the important thing is that the buffer is not
freed and that it's null terminated, and both hold for the ext4,
AFAICS.
I tend to agree with Brian and Ian at this point: return -ECHILD from
xfs_vn_get_link_inline() until xfs's inode resue vs. rcu walk
implications are fully dealt with. No way to fix this from VFS alone.
Thanks,
Miklos
next prev parent reply other threads:[~2021-11-15 9:23 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-11 3:39 [PATCH 1/2] vfs: check dentry is still valid in get_link() Ian Kent
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 [this message]
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
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='CAJfpegu4BwJD1JKngsrzUs7h82cYDGpxv0R1om=WGhOOb6pZ2Q@mail.gmail.com' \
--to=miklos@szeredi.hu \
--cc=bfoster@redhat.com \
--cc=david@fromorbit.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=raven@themaw.net \
--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).