[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250611-ihnen-gehackt-39b5a2c24db4@brauner>
Date: Wed, 11 Jun 2025 13:43:01 +0200
From: Christian Brauner <brauner@...nel.org>
To: NeilBrown <neil@...wn.name>
Cc: Alexander Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>,
Chuck Lever <chuck.lever@...cle.com>, Jeff Layton <jlayton@...nel.org>,
Amir Goldstein <amir73il@...il.com>, Jan Harkes <jaharkes@...cmu.edu>,
David Howells <dhowells@...hat.com>, Tyler Hicks <code@...icks.com>,
Miklos Szeredi <miklos@...redi.hu>, Carlos Maiolino <cem@...nel.org>, linux-fsdevel@...r.kernel.org,
coda@...cmu.edu, codalist@...a.cs.cmu.edu, linux-nfs@...r.kernel.org,
netfs@...ts.linux.dev, ecryptfs@...r.kernel.org, linux-unionfs@...r.kernel.org,
linux-xfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/5] Minor cleanup preparation for some dir-locking API
changes
On Mon, Jun 09, 2025 at 09:09:32AM +1000, NeilBrown wrote:
> The following 5 patches provide further cleanup that serves as
> preparation for some dir-locking API changes that I want to make. The
> most interesting is the last which makes another change to vfs_mkdir().
> As well as returning the dentry or consuming it on failure (a recent
> change) it now also unlocks on failure. This will be needed when we
> transition to locking just the dentry, not the whole directory.
All of the patches except the vfs_mkdir() one that Al is looking at
make sense as independent cleanups imho. So I'd take them unless I hear
screams.
Powered by blists - more mailing lists