[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJfpegu4BwJD1JKngsrzUs7h82cYDGpxv0R1om=WGhOOb6pZ2Q@mail.gmail.com>
Date: Mon, 15 Nov 2021 10:21:03 +0100
From: Miklos Szeredi <miklos@...redi.hu>
To: Dave Chinner <david@...morbit.com>
Cc: Ian Kent <raven@...maw.net>, xfs <linux-xfs@...r.kernel.org>,
"Darrick J. Wong" <djwong@...nel.org>,
Brian Foster <bfoster@...hat.com>,
Al Viro <viro@...iv.linux.org.uk>,
David Howells <dhowells@...hat.com>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] xfs: make sure link path does not go away at access
On Mon, 15 Nov 2021 at 00:18, Dave Chinner <david@...morbit.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
Powered by blists - more mailing lists