Re: [PATCH] misc: fastrpc: Ignore unsolicited DSP response sentinel

[Shawn Guo]

On Tue, Jul 28, 2026 at 09:17:34AM +0530, Ekansh Gupta wrote:
> On 27-07-2026 18:39, Shawn Guo wrote:
> > The DSP firmware on Nord targets emits an unsolicited glink message
> > during process teardown whose context field holds a fixed sentinel
> > (0xABCDABCD) rather than the context of an outstanding invocation.
> > fastrpc_rpmsg_callback() treats every inbound message as an invoke
> > response, so the sentinel is masked and shifted like any real response
> > ((0xABCDABCD & 0xFF0) >> 4 == 188) and looked up in the channel's
> > context idr.
> > 
> > This is not merely cosmetic. In the common case idr slot 188 is empty,
> > the lookup fails, and the driver only logs a spurious "No context ID
> > matches response" error on every teardown. But the context idr is shared
> > by every protection domain and the listener thread on the channel and is
> > filled cyclically over [1, FASTRPC_CTX_MAX]. If slot 188 holds a live
> > context when the sentinel arrives, the sentinel's return value is written
> > into that unrelated in-flight invocation and it is completed early. That
> > is a latent, timing-dependent bug that just does not happen to trigger in
> > current test runs.
> > 
> > Drop the sentinel before it is ever turned into a context lookup.
> > This removes both the log spam and the mis-completion race. A genuine
> > response can never be masked: a real context is (idr_index << 4) | pd
> > (at most 0xFF3) and can never equal the sentinel.
> > 
> > Lemans and other targets are unaffected: their DSP firmware does not send
> > this message, so the new check never fires.
> > 
> Sharing more details for this context:
> 
> On newer firmware, there is a support for DSP PD notification where DSP
> sends PD state notifications on certain states as per user request. PD
> exit notification is always sent by DSP which is with context id
> 0xABCDABCD. As of today, DSP notification framework is not supported by
> fastrpc lib or driver and it's safe to ignore this callback.

Ah, great information! I should have consulted you internally. I will
update.

> With this,
> 
> Reviewed-by: Ekansh Gupta <ekansh.gupta@xxxxxxxxxxxxxxxx>

Thank you, Ekansh!

Shawn