Re: [PATCH v2 4/6] ksmbd: defer CHANGE_NOTIFY completion instead of STATUS_NOT_IMPLEMENTED

It looks like this patch from Gaël has already implemented notify 
pending and cancel support. I will rebase on this patch.

I will send the remaining ksmbd notify patches soon.

On 7/9/26 08:06, Gaël Blivet-Bailly wrote:
> From: Gael Blivet<[email protected]>
> 
> smb2_notify() currently returns STATUS_NOT_IMPLEMENTED synchronously
> for every CHANGE_NOTIFY request. Genuine SMB2 servers never complete a
> CHANGE_NOTIFY spontaneously -- it's satisfied only by a real directory
> change or with STATUS_NOTIFY_CLEANUP when the watched handle is
> closed. macOS smbfs.kext depends on this deferred-completion contract:
> receiving STATUS_NOT_IMPLEMENTED instead makes it hard-freeze on
> unmount, since it never sees the cleanup it's waiting for.
> 
> Add a notify_pendings list on struct ksmbd_file (protected by the
> existing f_lock) and a notify_entry list_head on struct ksmbd_work to
> link onto it. smb2_notify() now replies STATUS_PENDING immediately and
> queues a deferred STATUS_NOTIFY_CLEANUP response on the watched
> handle; __ksmbd_close_fd() drains and sends any pending notifications
> when the handle is actually closed. The drain splices the list out
> under fp->f_lock first, then processes the detached copy without the
> lock -- smb2_notify() on another connection can be adding to the same
> list at the same time a close happens on this one, and
> ksmbd_conn_write() can sleep (it takes the connection's write mutex),
> so it must not be called while the spinlock is held.
> 
> Also handle the FileId=FFFF...FFFF share-root sentinel that macOS
> backupd sends to watch for changes without holding an open handle --
> without an immediate STATUS_PENDING/STATUS_NOTIFY_CLEANUP reply here,
> backupd aborts Time Machine setup with STATUS_FILE_CLOSED.
> 
> Signed-off-by: Gael Blivet<[email protected]>

-- 
ChenXiaoSong <[email protected]>
Chinese Homepage: https://chenxiaosong.com
English Homepage: https://chenxiaosong.com/en