Re: [PATCH] ksmbd: protect stream_del_pending with fp->f_lock

On Fri, Jul 10, 2026 at 1:51 AM Gaël Blivet-Bailly
<[email protected]> wrote:
>
> From: Gael Blivet <[email protected]>
>
> Follow-up to commit 36442851a4d1 ("ksmbd: route stream
> FileDispositionInformation through stream delete flag"): fp's
> stream_del_pending is read and written from three call sites
> (ksmbd_inode_pending_delete(), ksmbd_fd_set_delete_pending()/
> ksmbd_fd_clear_delete_pending(), and __ksmbd_inode_close()) with no
> locking at all, unlike every other piece of shared per-handle mutable
> state in this file, which uses fp->f_lock.
>
> A FileDispositionInformation SET_INFO racing a concurrent close on the
> same handle can see a stale value and skip removing the stream's
> xattr even though the client asked for deletion.
>
> Protect all three touch points with fp->f_lock, matching the existing
> convention (e.g. notify_pendings).
>
> Signed-off-by: Gael Blivet <[email protected]>
This patch has been combined with the "ksmbd: route stream
FileDispositionInformation through stream delete flag" patch.