From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3E7F544684C for ; Wed, 29 Jul 2026 09:44:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785318255; cv=none; b=LlmEA5MkIZVRznc+rL+ult43Zs0HLIFlB2UL0rrVtbsq8Jvnwox/H1PYtKFMyg6M6HpB+5ez3XpsQX8Tp/lVsHBgkj2pn6dkmOl6s22FzyT+m/XJpsxsBX2d+754EsMiuHPDNTu2KUW26Vzj+vSphbAqrOShvfhc5o3/0zQJQkc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785318255; c=relaxed/simple; bh=saI9PuwPHTBpEVPA90scJH6tqyH/J2+9aKtypOe5QgE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Gzq3IjaNi3tuDfL+vsHFqNi4eSoy1DqDJnJ61gDhwhcgpz0zP8U0fSZjSwBiSxE5rJT0gCwP4eNxrLhdm6Yb28McSqppPJbE8LCeixNc/nBMeyvTQ0BziafpdNrgK6dHtrEW0jSoMTO+5duwYh4wOaeKt8bJI7XeLXXTIujO1PQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FaR7gpCZ; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FaR7gpCZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C6DE41F00A3A; Wed, 29 Jul 2026 09:44:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785318253; bh=NxTGX6dFy6gHVF/+ey/TcmXGu7o26iNy9lTjKHTSQrw=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=FaR7gpCZgkTaySyt/CNqtB2twulmMDi8uEHy50nbgpfxQuFEY9/DYp1TxlACa+PMe VNQEf5+oP8nIPNoIJ9WxzY22nMnoNTfnd2axSA3ToVfpTf7+ZS2EhFoemCE8shB4Y8 EGXWeiiukpxM2SRkDbQXtidK/XfXEaKjqCM+iwZxv/1iPtJk2SFQlEMPDrDOfSKNH1 lFRzO44m4G3nuMSuw//D7RGkfLfNWptL46ql9h/GPS7lw9PxsWA4O+uaZi4+t7CweC ntSzBpv7XI/T0zIC+sDGkoaEG0oetVVQSS33I56mhdnVoKHf8a1DEBSEAOkbhR8eeR pVBmBhLYxXw8Q== From: srini@kernel.org To: gregkh@linuxfoundation.org Cc: linux-kernel@vger.kernel.org, Shawn Guo , Ekansh Gupta , Srinivas Kandagatla Subject: [PATCH 10/10] misc: fastrpc: Drop unhandled DSP PD exit notification Date: Wed, 29 Jul 2026 10:43:52 +0100 Message-ID: <20260729094352.111065-11-srini@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260729094352.111065-1-srini@kernel.org> References: <20260729094352.111065-1-srini@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Shawn Guo 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 Signed-off-by: Shawn Guo Signed-off-by: Srinivas Kandagatla --- drivers/misc/fastrpc.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c index 93aa6556bd47..65f2154e3a1d 100644 --- a/drivers/misc/fastrpc.c +++ b/drivers/misc/fastrpc.c @@ -51,6 +51,17 @@ /* Sequence number occupies bits 63:16 of the ctxid / message context */ #define FASTRPC_CTXID_SEQ_SHIFT 16 #define FASTRPC_CTXID_SEQ_MASK GENMASK_ULL(63, 16) + +/* + * 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 this fixed sentinel + * in the context field rather than the context of an outstanding invocation. + * Since the fastrpc driver does not support the DSP PD notification framework, + * this message must be dropped rather than matched against the context idr. + */ +#define FASTRPC_DSP_PD_NOTIFY_CTX 0xABCDABCD + #define INIT_FILELEN_MAX (2 * 1024 * 1024) #define INIT_FILE_NAMELEN_MAX (128) #define FASTRPC_DEVICE_NAME "fastrpc" @@ -2701,6 +2712,14 @@ static int fastrpc_rpmsg_callback(struct rpmsg_device *rpdev, void *data, if (!cctx) return -ENODEV; + /* + * A PD exit notification from the DSP PD notification framework carries + * this sentinel rather than a real context. Drop it: a real context is + * (idr_index << 4) | pd and can never collide with this value. + */ + if (rsp->ctx == FASTRPC_DSP_PD_NOTIFY_CTX) + return 0; + ctxid = FIELD_GET(FASTRPC_CTXID_MASK, rsp->ctx); spin_lock_irqsave(&cctx->lock, flags); -- 2.53.0