The only change in this v4 over v3 are to replace lock_sync with an
acquire/release pair which builds correctly when lockdep isn't enabled,
to add the 7th patch which I previously mentioned, and to include
linux-kernel so that sashiko gets to see the series.

Previous intro:

Hi,
 As you know I am working on changes to locking for directory operations
such as lookup/create/remove/rename.  The ultimate goal is for the VFS
to lock the dentry, not the parent directory, and to push the i_rwsem
parent locking down into the filesystems where it can be kept, removed,
or adjusted as best fits each filesystem.

The next step is to change the order of locking for d_alloc_parallel() -
which allocates a locked (in-lookup) dentry or waits for an existing
dentry to be unlocked.  Currently d_alloc_parallel() is ordered below
i_rwsem on parent, so you cannot wait on i_rwsem while holding a locked
(in-lookup) dentry.

To push i_rwsem into filesystems I need to push i_rwsem below d_alloc_parallel(),
so code can wait for i_rwsem while holding an in-lookup dentry, but won't be
able to wait in d_alloc_parallel() while holding i_rwsem.

There are two broad changes that are needed before that order can be
swapped.  This series sets the direction.  Subsequent patches which I
hope can also land this cycle spread those changes throughout
filesystems.

The two changes are:
1 - don't call d_alloc_parallel() while holding i_rwsem.
   This involves introducing d_alloc_trylock() and changing
   some places to drop i_rwsem before taking d_alloc_parallel()
   for this to work they will need to know if the lock is shared
   or exclusive so LOOKUP_SHARED is added.

2 - don't d_drop() a dentry while it being worked on.  This might
   not be entirely needed yet, but it will be needed soon and doing it
   now is a convenient time, and it helps make the end result clearer.
   Calling d_drop() effectively unlocks an in-lookup denty.
   It is OK for a filesystem to do this *after* an operation has
   completed, whether in success or failure.  Doing it before completion
   will allow another dentry to be allocated maybe too early.

   Enhancing d_splice_alias() to handle hashed dentries is key to
   removing the need to d_drop() in filesystems.  Though not strictly
   necessary, this allows d_add() to be removed as there will be nothing
   that d_add() does which cannot be done with d_splice_alias()

This set of 6 patches makes core-VFS changes. After this I have
 - 7 nfs patches
 - 6 afs patches
 - 4 smb/client patches
 - 3 cephfs patches
 - 2 fuse patches
 - one each for shmem, code, configfs, hostfs, procfs, ovl
and a patch to d_add_ci() which affects xfs and ntfs.

Once all of those have landed I have 4 patches to remove deprecated interfaces.
All of these can be found at
   https://github.com/neilbrown/linux/commits/pdirops


If all goes to plan, then in the next cycle a few patches will invert the
lock order and remove LOOKUP_SHARED.  Then we can get on to the really
fun stuff! (branch pdirops-next)

Thanks,
NeilBrown


 [PATCH v4 1/7] VFS: fix various typos in documentation for
 [PATCH v4 2/7] VFS: enhance d_splice_alias() to handle hashed
 [PATCH v4 3/7] VFS: introduce d_alloc_trylock()
 [PATCH v4 4/7] VFS: add d_duplicate()
 [PATCH v4 5/7] VFS: Add LOOKUP_SHARED flag.
 [PATCH v4 6/7] VFS: add lockdep monitoring of DCACHE_PAR_LOOKUP lock.
 [PATCH v4 7/7] VFS: reserve a d_flags bit for fs-specific usage

On Sat, 05 Sep 2026 07:48:09 +1000, NeilBrown wrote:
> The only change in this v4 over v3 are to replace lock_sync with an
> acquire/release pair which builds correctly when lockdep isn't enabled,
> to add the 7th patch which I previously mentioned, and to include
> linux-kernel so that sashiko gets to see the series.
> 
> Previous intro:
> 
> [...]

Applied to the vfs-7.4.lookup branch of the vfs/vfs.git tree.
Patches in the vfs-7.4.lookup branch should appear in linux-next soon.

Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.

It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.

Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs-7.4.lookup

[1/7] VFS: fix various typos in documentation for start_creating start_removing etc
      https://git.kernel.org/vfs/vfs/c/f8550827bf3d
[2/7] VFS: enhance d_splice_alias() to handle hashed dentries
      https://git.kernel.org/vfs/vfs/c/f1ac607f786f
[3/7] VFS: introduce d_alloc_trylock()
      https://git.kernel.org/vfs/vfs/c/17c7d109d8c9
[4/7] VFS: add d_duplicate()
      https://git.kernel.org/vfs/vfs/c/33d76519f0cc
[5/7] VFS: Add LOOKUP_SHARED flag.
      https://git.kernel.org/vfs/vfs/c/cc47a1ba1983
[6/7] VFS: add lockdep monitoring of DCACHE_PAR_LOOKUP lock.
      https://git.kernel.org/vfs/vfs/c/59492f9991dc
[7/7] VFS: reserve a d_flags bit for fs-specific usage
      https://git.kernel.org/vfs/vfs/c/fd96e30426ff

Hi,
 is there any chance these might land this cycle?  I was hoping to add a
 bunch of follow-on per-fs patches, but I cannot without this prep.

Thanks,
NeilBrown


On Sat, 05 Sep 2026, NeilBrown wrote:
> The only change in this v4 over v3 are to replace lock_sync with an
> acquire/release pair which builds correctly when lockdep isn't enabled,
> to add the 7th patch which I previously mentioned, and to include
> linux-kernel so that sashiko gets to see the series.
> 
> Previous intro:
> 
> Hi,
>  As you know I am working on changes to locking for directory operations
> such as lookup/create/remove/rename.  The ultimate goal is for the VFS
> to lock the dentry, not the parent directory, and to push the i_rwsem
> parent locking down into the filesystems where it can be kept, removed,
> or adjusted as best fits each filesystem.
> 
> The next step is to change the order of locking for d_alloc_parallel() -
> which allocates a locked (in-lookup) dentry or waits for an existing
> dentry to be unlocked.  Currently d_alloc_parallel() is ordered below
> i_rwsem on parent, so you cannot wait on i_rwsem while holding a locked
> (in-lookup) dentry.
> 
> To push i_rwsem into filesystems I need to push i_rwsem below d_alloc_parallel(),
> so code can wait for i_rwsem while holding an in-lookup dentry, but won't be
> able to wait in d_alloc_parallel() while holding i_rwsem.
> 
> There are two broad changes that are needed before that order can be
> swapped.  This series sets the direction.  Subsequent patches which I
> hope can also land this cycle spread those changes throughout
> filesystems.
> 
> The two changes are:
> 1 - don't call d_alloc_parallel() while holding i_rwsem.
>    This involves introducing d_alloc_trylock() and changing
>    some places to drop i_rwsem before taking d_alloc_parallel()
>    for this to work they will need to know if the lock is shared
>    or exclusive so LOOKUP_SHARED is added.
> 
> 2 - don't d_drop() a dentry while it being worked on.  This might
>    not be entirely needed yet, but it will be needed soon and doing it
>    now is a convenient time, and it helps make the end result clearer.
>    Calling d_drop() effectively unlocks an in-lookup denty.
>    It is OK for a filesystem to do this *after* an operation has
>    completed, whether in success or failure.  Doing it before completion
>    will allow another dentry to be allocated maybe too early.
> 
>    Enhancing d_splice_alias() to handle hashed dentries is key to
>    removing the need to d_drop() in filesystems.  Though not strictly
>    necessary, this allows d_add() to be removed as there will be nothing
>    that d_add() does which cannot be done with d_splice_alias()
> 
> This set of 6 patches makes core-VFS changes. After this I have
>  - 7 nfs patches
>  - 6 afs patches
>  - 4 smb/client patches
>  - 3 cephfs patches
>  - 2 fuse patches
>  - one each for shmem, code, configfs, hostfs, procfs, ovl
> and a patch to d_add_ci() which affects xfs and ntfs.
> 
> Once all of those have landed I have 4 patches to remove deprecated interfaces.
> All of these can be found at
>    https://github.com/neilbrown/linux/commits/pdirops
> 
> 
> If all goes to plan, then in the next cycle a few patches will invert the
> lock order and remove LOOKUP_SHARED.  Then we can get on to the really
> fun stuff! (branch pdirops-next)
> 
> Thanks,
> NeilBrown
> 
> 
>  [PATCH v4 1/7] VFS: fix various typos in documentation for
>  [PATCH v4 2/7] VFS: enhance d_splice_alias() to handle hashed
>  [PATCH v4 3/7] VFS: introduce d_alloc_trylock()
>  [PATCH v4 4/7] VFS: add d_duplicate()
>  [PATCH v4 5/7] VFS: Add LOOKUP_SHARED flag.
>  [PATCH v4 6/7] VFS: add lockdep monitoring of DCACHE_PAR_LOOKUP lock.
>  [PATCH v4 7/7] VFS: reserve a d_flags bit for fs-specific usage
> 
>