[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250917204200.GB39973@ZenIV>
Date: Wed, 17 Sep 2025 21:42:00 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Amir Goldstein <amir73il@...il.com>
Cc: Jan Kara <jack@...e.cz>, Jakub Acs <acsjakub@...zon.de>,
linux-unionfs@...r.kernel.org, Miklos Szeredi <miklos@...redi.hu>,
linux-kernel@...r.kernel.org, stable@...r.kernel.org,
Christian Brauner <brauner@...nel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH] ovl: check before dereferencing s_root field
On Wed, Sep 17, 2025 at 01:07:45PM +0200, Amir Goldstein wrote:
> diff --git a/fs/dcache.c b/fs/dcache.c
> index 60046ae23d514..8c9d0d6bb0045 100644
> --- a/fs/dcache.c
> +++ b/fs/dcache.c
> @@ -1999,10 +1999,12 @@ struct dentry *d_make_root(struct inode *root_inode)
>
> if (root_inode) {
> res = d_alloc_anon(root_inode->i_sb);
> - if (res)
> + if (res) {
> + root_inode->i_opflags |= IOP_ROOT;
> d_instantiate(res, root_inode);
Umm... Not a good idea - if nothing else, root may end up
being attached someplace (normal with nfs, for example).
But more fundamentally, once we are into ->kill_sb(), let alone
generic_shutdown_super(), nobody should be playing silly buggers
with the filesystem. Sure, RCU accesses are possible, but messing
around with fhandles? ->s_root is not the only thing that might
be no longer there.
What the fuck is fsnotify playing at?
Powered by blists - more mailing lists