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

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

[Shawn Guo]

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.

Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
 drivers/misc/fastrpc.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index d86e79134c68..be9f102690f6 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -38,6 +38,15 @@
 #define FASTRPC_INIT_HANDLE	1
 #define FASTRPC_DSP_UTILITIES_HANDLE	2
 #define FASTRPC_CTXID_MASK (0xFF0)
+
+/*
+ * DSP firmware on some targets (e.g. the Nord remoteproc) sends an unsolicited
+ * message during process teardown that carries this sentinel in the context
+ * field instead of the context of an outstanding invocation. It is not a
+ * response, so it must be dropped rather than matched against the context idr.
+ */
+#define FASTRPC_RSP_CTX_SENTINEL	0xABCDABCD
+
 #define INIT_FILELEN_MAX (2 * 1024 * 1024)
 #define INIT_FILE_NAMELEN_MAX (128)
 #define FASTRPC_DEVICE_NAME	"fastrpc"
@@ -2552,6 +2561,14 @@ static int fastrpc_rpmsg_callback(struct rpmsg_device *rpdev, void *data,
 	if (!cctx)
 		return -ENODEV;
 
+	/*
+	 * A sentinel context marks an unsolicited message from the DSP rather
+	 * than a response to an outstanding invocation. Drop it: a real context
+	 * is (idr_index << 4) | pd and can never collide with this value.
+	 */
+	if (rsp->ctx == FASTRPC_RSP_CTX_SENTINEL)
+		return 0;
+
 	ctxid = ((rsp->ctx & FASTRPC_CTXID_MASK) >> 4);
 
 	spin_lock_irqsave(&cctx->lock, flags);
-- 
2.43.0

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

[Ekansh Gupta]

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.

With this,

Reviewed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>

> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
>  drivers/misc/fastrpc.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> index d86e79134c68..be9f102690f6 100644
> --- a/drivers/misc/fastrpc.c
> +++ b/drivers/misc/fastrpc.c
> @@ -38,6 +38,15 @@
>  #define FASTRPC_INIT_HANDLE	1
>  #define FASTRPC_DSP_UTILITIES_HANDLE	2
>  #define FASTRPC_CTXID_MASK (0xFF0)
> +
> +/*
> + * DSP firmware on some targets (e.g. the Nord remoteproc) sends an unsolicited
> + * message during process teardown that carries this sentinel in the context
> + * field instead of the context of an outstanding invocation. It is not a
> + * response, so it must be dropped rather than matched against the context idr.
> + */
> +#define FASTRPC_RSP_CTX_SENTINEL	0xABCDABCD
> +
>  #define INIT_FILELEN_MAX (2 * 1024 * 1024)
>  #define INIT_FILE_NAMELEN_MAX (128)
>  #define FASTRPC_DEVICE_NAME	"fastrpc"
> @@ -2552,6 +2561,14 @@ static int fastrpc_rpmsg_callback(struct rpmsg_device *rpdev, void *data,
>  	if (!cctx)
>  		return -ENODEV;
>  
> +	/*
> +	 * A sentinel context marks an unsolicited message from the DSP rather
> +	 * than a response to an outstanding invocation. Drop it: a real context
> +	 * is (idr_index << 4) | pd and can never collide with this value.
> +	 */
> +	if (rsp->ctx == FASTRPC_RSP_CTX_SENTINEL)
> +		return 0;
> +
>  	ctxid = ((rsp->ctx & FASTRPC_CTXID_MASK) >> 4);
>  
>  	spin_lock_irqsave(&cctx->lock, flags);

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@oss.qualcomm.com>

Thank you, Ekansh!

Shawn