Re: [PATCH] ALSA: ump: Drain sequencer callbacks before freeing their client

[Takashi Iwai <tiwai@suse.de>]

On Sat, 24 Oct 2026 10:02:47 +0200,
Cen Zhang wrote:
> 
> seq_ump_client_free() cancels group_notify_work while the endpoint still
> publishes seq_ops and seq_client. A received Function Block update can
> enter the sequencer callback after cancellation and queue the work again.
> Even disabling the work cannot protect a callback that already loaded
> seq_client and then resumes after the client has been freed.
> 
> A USB UMP endpoint can continue receiving while its sequencer binding
> is removed. The following order uses the same endpoint and client:
> 
>   Sequencer binding removal             UMP input completion
>   -------------------------             --------------------
>   cancel_work_sync()
>                                         load seq_ops and seq_client
>   delete sequencer client
>   clear endpoint binding
>   kfree(client)
>                                         schedule group_notify_work
>                                         read client->seq_client
> 
> Cover all calls through seq_ops with SRCU in the UMP core. Withdraw the
> operations pointer and wait for those callbacks before canceling work
> and deleting the client. No producer can then queue work after the final
> cancellation, and both the client and callback code remain available
> until the last in-flight callback returns.
> 
> Publish seq_ops with release/acquire ordering so the separately stored
> seq_client is initialized before any callback uses it. Use SRCU because
> sequencer notification delivery can sleep; no callback needs to change
> its existing execution context or allocation behavior.
> 
> Fixes: 4a16a3af0571 ("ALSA: seq: ump: Handle FB info update")
> Assisted-by: LLM
> Signed-off-by: Cen Zhang <zzzccc427@gmail.com>

Applied now.  Thanks.


Takashi