Re: [PATCH v2 0/3] smb/client(cifs): prepare for VFS locking changes.
From: Namjae Jeon
Date: Wed Oct 21 2026 - 09:55:04 EST
On Tue, Sep 29, 2026 at 11:44 AM NeilBrown <neilb@xxxxxxxxxxx> wrote:
>
> The previous version of this series had a couple of problems reported by sashiko,
> both in 2/3.
> 1/ an error from cifs_lookup() wasn't handled properly - it should be fatal
> 2/ The d_is_positive() tested the wrong dentry.
>
> Original intro message below.
> Thanks,
> NeilBrown
>
>
> I am working on changes to directory locking. The medium term goal is
> to lift d_alloc_parallel() locking above i_rwsem, so d_alloc_paralle()
> can be run unlocked, and consequently cannot be called when ->i_rwsem is
> held.
>
> The requires:
> 1/ that d_alloc_parallel() not be called while i_rwsem is held. cifs
> does this in a couple of places. A new interface d_alloc_trylock()
> is now available and can be used instead.
>
> 2/ a dentry must not be d_drop()ed while an operation is ongoing, as an
> unlocked d_alloc_parallel() would then be able to create a new
> dentry with the same name. In particular d_rehash() must be phased
> out as it won't be safe. This particularly affects the mechanism to
> block lookups/revalidates while an unlink/rename is happening. The
> mechanism is changed to use one similar to how NFS addresses this
> needed, though using the new LOOKUP_PRIVATE flag.
>
> The patches depend on patches recently added to the vfs tree. I would
> prefer these land in that tree too with an Acked-by or similar from cifs
> maintainers.
>
> Thanks,
> NeilBrown
>
> [PATCH v2 1/3] smb/client: don't unhash and rehash to prevent new
> [PATCH v2 2/3] smb/client: use d_alloc_trylock in
> [PATCH v2 3/3] smb/client: Use d_alloc_trylock() in
Looks good to me:)
Acked-by: Namjae Jeon <linkinjeon@xxxxxxxxxx>
Thanks!