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

> +       /*
> +        * Transfer ownership of the async id to in_work; it stays reserved
> +        * until in_work is freed after the deferred response is sent on
> +        * close, so it can't be reused for an unrelated async response.
> +        */
> +       in_work->async_id = work->async_id;
> +       work->async_id = 0;
> +       release_async_work(work);
I have one concern about the CHANGE_NOTIFY async lifecycle and CANCEL handling.
The notify request is registered as async and then released
immediately. After that, the deferred response is kept only on the fp
pending list.
However, SMB2 CANCEL lookup walks only conn async_requests. Because of
this, a client-issued SMB2 CANCEL cannot find and cancel the deferred
CHANGE_NOTIFY anymore. The request remains pending until file close...

> +
> +       spin_lock(&fp->f_lock);
> +       list_add_tail(&in_work->notify_entry, &fp->notify_pendings);
> +       spin_unlock(&fp->f_lock);
> +
> +       ksmbd_fd_put(work, fp);
> +       work->send_no_response = 1;
> +       return 0;
>  }