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

ChenXiaoSong <[email protected]>
Newsgroups org.kernel.vger.linux-cifs
Message-ID <[email protected]>
Would it be better to do it like the following?

```
int smb2_notify()
{
     setup_async_work(..., smb2_notify_cancel_fn, ...);

     smb2_send_interim_resp(work, STATUS_PENDING);
     wait_for_completion_interruptible(); // woken up by 
smb2_notify_cancel_fn()

     if (work->state == KSMBD_WORK_CANCELLED) {
         smb2_send_interim_resp(work, STATUS_CANCELLED);
         work->send_no_response = 1;
         goto out;
     }

     // Add my implementation of notification events here.
}
```

On 7/10/26 14:48, ChenXiaoSong wrote:
> 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 <[email protected]>
Chinese Homepage: https://chenxiaosong.com
English Homepage: https://chenxiaosong.com/en
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.