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

[ChenXiaoSong <chenxiaosong@chenxiaosong.com>]

Hi Gaël,

Thanks for your patches.

I mean sending STATUS_CANCELLED in smb2_notify() (not in 
smb2_notify_cancel_fn()). The event notification and STATUS_CANCELLED 
response should be handled in smb2_notify().

You can refer to the implementation of smb2_lock():

```
int smb2_lock()
{
     smb2_send_interim_resp(work, STATUS_PENDING);
     ksmbd_vfs_posix_lock_wait(flock); // woken up by 
smb2_remove_blocked_lock()

     smb2_send_interim_resp(work, STATUS_CANCELLED);
     work->send_no_response = 1
}
```

I have already implemented the complete notify feature, but since my 
patch series is quite large, I still need to make some changes and split 
it into smaller patches that are easier to review.

On 7/10/26 13:59, Gaël Blivet wrote:
> Because cancel_fn runs under conn->request_lock, smb2_cancel() holds it as a spinlock while walking async_requests, so cancel_fn can’t sleep. ksmbd_conn_write() takes conn->srv_mutex and can block on the actual socket write too, so calling it there directly would mean sleeping under a spinlock.
> 
> smb2_notify_cancel_fn() only does the non-sleeping parts inline (list removal, freeing cancel_argv, releasing the async id), same as smb2_remove_blocked_lock() elsewhere in this file, and pushes the actual response send to a workqueue.

-- 
ChenXiaoSong <chenxiaosong@chenxiaosong.com>
Chinese Homepage: https://chenxiaosong.com
English Homepage: https://chenxiaosong.com/en