Re: [PATCH 11/11] VFS: introduce d_alloc_noblock() and d_alloc_locked()

[Al Viro <viro@zeniv.linux.org.uk>]

On Tue, Aug 12, 2025 at 12:25:14PM +1000, NeilBrown wrote:
> Several filesystems use the results of readdir to prime the dcache.
> These filesystems use d_alloc_parallel() which can block if there is a
> concurrent lookup.  Blocking in that case is pointless as the lookup
> will add info to the dcache and there is no value in the readdir waiting
> to see if it should add the info too.
> 
> Also these calls to d_alloc_parallel() are made while the parent
> directory is locked.  A proposed change to locking will lock the parent
> later, after d_alloc_parallel().  This means it won't be safe to wait in
> d_alloc_parallel() while holding the directory lock.
> 
> So this patch introduces d_alloc_noblock() which doesn't block
> but instead returns ERR_PTR(-EWOULDBLOCK).  Filesystems that prime the
> dcache now use that and ignore -EWOULDBLOCK errors as harmless.
> 
> A few filesystems need more than -EWOULDBLOCK - they need to be able to
> create the missing dentry within the readdir.  procfs is a good example
> as the inode number is not known until the lookup completes, so readdir
> must perform a full lookup.
> 
> For these filesystems d_alloc_locked() is provided.  It will return a
> dentry which is already d_in_lookup() but will also lock it against
> concurrent lookup.  The filesystem's ->lookup function must co-operate
> by calling lock_lookup() before proceeding with the lookup.  This way we
> can ensure exclusion between a lookup performed in ->iterate_shared and
> a lookup performed in ->lookup.  Currently this exclusion is provided by
> waiting in d_wait_lookup().  The proposed changed to dir locking will
> mean that calling d_wait_lookup() (in readdir) while already holding
> i_rwsem could deadlock.

The last one is playing fast and loose with one assertion that is used
in quite a few places in correctness proofs - that the only thing other
threads do to in-lookup dentries is waiting on them (and that - only
in d_wait_lookup()).  I can't tell whether it will be a problem without
seeing what you do in the users of that thing, but that creates an
unpleasant areas to watch out for in the future ;-/

Which filesystems are those, aside of procfs?