[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251201085659.GC3538@ZenIV>
Date: Mon, 1 Dec 2025 08:56:59 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: NeilBrown <neil@...wn.name>
Cc: Amir Goldstein <amir73il@...il.com>,
Christian Brauner <brauner@...nel.org>,
Val Packett <val@...kett.cool>, Jan Kara <jack@...e.cz>,
linux-fsdevel@...r.kernel.org, Jeff Layton <jlayton@...nel.org>,
Chris Mason <clm@...com>, David Sterba <dsterba@...e.com>,
David Howells <dhowells@...hat.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Danilo Krummrich <dakr@...nel.org>, Tyler Hicks <code@...icks.com>,
Miklos Szeredi <miklos@...redi.hu>,
Chuck Lever <chuck.lever@...cle.com>,
Olga Kornievskaia <okorniev@...hat.com>,
Dai Ngo <Dai.Ngo@...cle.com>, Namjae Jeon <linkinjeon@...nel.org>,
Steve French <smfrench@...il.com>,
Sergey Senozhatsky <senozhatsky@...omium.org>,
Carlos Maiolino <cem@...nel.org>,
John Johansen <john.johansen@...onical.com>,
Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
"Serge E. Hallyn" <serge@...lyn.com>,
Stephen Smalley <stephen.smalley.work@...il.com>,
Ondrej Mosnacek <omosnace@...hat.com>,
Mateusz Guzik <mjguzik@...il.com>,
Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
Stefan Berger <stefanb@...ux.ibm.com>,
"Darrick J. Wong" <djwong@...nel.org>, linux-kernel@...r.kernel.org,
netfs@...ts.linux.dev, ecryptfs@...r.kernel.org,
linux-nfs@...r.kernel.org, linux-unionfs@...r.kernel.org,
linux-cifs@...r.kernel.org, linux-xfs@...r.kernel.org,
linux-security-module@...r.kernel.org, selinux@...r.kernel.org
Subject: Re: [PATCH] fuse: fix conversion of fuse_reverse_inval_entry() to
start_removing()
On Mon, Dec 01, 2025 at 07:50:43PM +1100, NeilBrown wrote:
> Why was the original code locking the parent inode? Whatever that was
> protecting, we need to keep protecting it. That is what
> start_removing_dentry() is there to do.
We need to find out what it's protecting, rather than cargo-culting it
indefinitely. If nothing else, it's a place with uncommon use of
inode_lock; we need to know which properties of current locking
scheme does it expect there. Thus the question to Miklos...
Powered by blists - more mailing lists