Message-ID: <20250608230952.20539-1-neil@brown.name>
Date: Mon,  9 Jun 2025 09:09:32 +1000
From: NeilBrown <neil@...wn.name>
To: Alexander Viro <viro@...iv.linux.org.uk>,
	Christian Brauner <brauner@...nel.org>,
	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>
Cc: 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: [PATCH 0/5] Minor cleanup preparation for some dir-locking API changes

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.

This leaves some rather clumsy code in overlayfs.  Overlayfs sometimes
takes a rename lock (two directories) and then possibly does a
vfs_mkdir() in one of those directories.  When that fails we now need to
unlock only the other directory.

I hope to go through overlayfs to narrow the directory locking so each
lock only covers a single operation (possibly including a lookup first).
That should remove the clumsiness and will also be needed for the
proposed API change.

As well as the cleanups here I have a few for smb/server.  I will send
those separately as they deserve careful review by the smb team and I
don't want them to be buried in this patch set.

After these, and the mentioned overlayfs changes, I have a series which
adds a collection of APIs with names like "lookup_and_lock()" which
combine the locking and the lookup, and then a set which changes all
code which currently locks a directory for name-based operations to
instead use the new look_and_lock() interfaces.  This will mean that the
changes to directory locking can be done in one central place.

After that there are a few more cleanups to stop filesystems from usng
d_drop() in the middle of name operations (at the end is OK, but not in
the middle) and then the core patches for this work which introduce an
alternate way to provide all the locking that the VFS needs for name
operations without taking i_rw_sem.  Filesystems can then opt into using
only this locking and to not depend on i_rw_sem.  This allows create and
remove of different names is the same directory to continue concurrently
with each other and with renames.  Renames are also concurrent though
cross-directory renames block some other cross-directory renames in the
same part of the tree.

Note that i_rw_sem will still be used for the target of rmdir, and will
still be held as a shared lock by readdir() so that we never try reading
in a directory being removed.  It might still be used (shared) for
lookups for the same reason, though I haven't completely settled my
design there yet.

Thanks,
NeilBrown

 [PATCH 1/5] VFS: merge lookup_one_qstr_excl_raw() back into
 [PATCH 2/5] VFS: Minor fixes for porting.rst
 [PATCH 3/5] coda: use iterate_dir() in coda_readdir()
 [PATCH 4/5] exportfs: use lookup_one_unlocked()
 [PATCH 5/5] Change vfs_mkdir() to unlock on failure.

Powered by blists - more mailing lists