UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification - #1698
UPSTREAM: misc: fastrpc: Drop unhandled DSP PD exit notification#1698Jianping (Jianping-Li) wants to merge 1 commit into
Conversation
🔨 Build Failure Analysis — PR #1698PR: #1698
VerdictThis is not a compilation failure. The build failed during the pre-merge automerge phase due to a merge conflict in 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1698PR: #1698
VerdictThis is not a compilation failure. The build failed during the pre-build automerge/integration phase due to a merge conflict in 📎 Detailed analysis: Full report |
PR #1698 — validate-patchPR: #1698
Final Summary
|
PR #1698 — checker-log-analyzerPR: #1698
Detailed report: Full report
|
Newer DSP firmware implements a PD (Protection Domain) notification framework that sends PD state notifications upon request. The PD exit notification is unconditionally sent by the DSP with a fixed sentinel 0xABCDABCD in the context field. 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. Since neither the fastrpc library nor the driver supports the DSP PD notification framework, it is safe to drop the PD exit notification 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. Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srini@kernel.org> Link: https://patch.msgid.link/20260729094352.111065-11-srini@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
6e7ef61 to
0590640
Compare
3 participants
Newer DSP firmware implements a PD (Protection Domain) notification framework that sends PD state notifications upon request. The PD exit notification is unconditionally sent by the DSP with a fixed sentinel 0xABCDABCD in the context field.
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.
Since neither the fastrpc library nor the driver supports the DSP PD notification framework, it is safe to drop the PD exit notification 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.
Link: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/misc/fastrpc.c?id=5533bb4bc53c6cd401b9b329d7e26802fd5aa1f5
CRs-Fixed: 4633198