[PATCH v13 0/4] misc: fastrpc: Add polling mode support

[PATCH v13 0/4] misc: fastrpc: Add polling mode support

[Ekansh Gupta]

This patch series adds polling mode feature that have been missing in
upstream FastRPC driver.

- Add changes to move fdlist to ctx structure to avoid code duplicacy.
- Update context mask to support polling mode.
- Add changes to support polling feature.

Userspace change: https://github.com/qualcomm/fastrpc/pull/258
Patch [v12]: https://lore.kernel.org/all/20260521054539.128651-1-ekansh.gupta@oss.qualcomm.com/

Changes in v13:
  - Fixed race between recycled ctxid and late glink response.

Changes in v12:
  - Fixed poll_mode_supported check.

Changes in v11:
  - Moved back to read_poll*.
  - Improved error handling.

Changes in v10:
  - Add milos and sar2130p to fastrpc_poll_supported_machines. 
  - Updated comment for supported platform list.

Changes in v9:
  - Added platform support check.
  - Moved to readl as per Luben's suggestion.
  - Cleaned up fastrpc_wait_for_completion().

Changes in v8:
  - Added more comments.

Changes in v7:
  - Fixed warnings.
  - Fixed commit text.
  - Addressed clean-up comments.

Changes in v6:
  - Fixed poll memory calculation.
  - Added few formatting changes.

Changes in v5:
  - Add more details in commit text.

Changes in v4:
  - Replace hardcoded ctxid mask with GENMASK.
  - Fixed commit text.

Changes in v3:
  - Resolve compilation warning.

Changes in v2:
  - Added comments and fixed commit text.
  - Defined context id position as a macro.
  - Added new IOCTL to control polling mode as always enabling
    it might cause excess power consumption.
  - Cleaned up polling mode implementation.

Ekansh Gupta (4):
  misc: fastrpc: Move fdlist to invoke context structure
  misc: fastrpc: Replace hardcoded ctxid mask with GENMASK
  misc: fastrpc: Expand context ID mask for DSP polling mode support
  misc: fastrpc: Add polling mode support for fastRPC driver

 drivers/misc/fastrpc.c      | 214 ++++++++++++++++++++++++++++++++----
 include/uapi/misc/fastrpc.h |  29 +++++
 2 files changed, 223 insertions(+), 20 deletions(-)

-- 
2.34.1

[PATCH v13 1/4] misc: fastrpc: Move fdlist to invoke context structure

[Ekansh Gupta]

The fdlist is currently part of the meta buffer which is set during
fastrpc_get_args(), this fdlist is getting recalculated during
fastrpc_put_args().

Move fdlist to the invoke context structure to improve maintainability
and reduce redundancy. This centralizes its handling and simplifies
meta buffer preparation and reading logic.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
---
 drivers/misc/fastrpc.c | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index d86e79134c68..02c2765e1188 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -233,6 +233,7 @@ struct fastrpc_invoke_ctx {
 	int pid;
 	int client_id;
 	u32 sc;
+	u64 *fdlist;
 	u32 *crc;
 	u64 ctxid;
 	u64 msg_sz;
@@ -1063,6 +1064,7 @@ static int fastrpc_get_args(u32 kernel, struct fastrpc_invoke_ctx *ctx)
 	rpra = ctx->buf->virt;
 	list = fastrpc_invoke_buf_start(rpra, ctx->nscalars);
 	pages = fastrpc_phy_page_start(list, ctx->nscalars);
+	ctx->fdlist = (u64 *)(pages + ctx->nscalars);
 	args = (uintptr_t)ctx->buf->virt + metalen;
 	rlen = pkt_size - metalen;
 	ctx->rpra = rpra;
@@ -1165,18 +1167,11 @@ static int fastrpc_put_args(struct fastrpc_invoke_ctx *ctx,
 	union fastrpc_remote_arg *rpra = ctx->rpra;
 	struct fastrpc_user *fl = ctx->fl;
 	struct fastrpc_map *mmap = NULL;
-	struct fastrpc_invoke_buf *list;
-	struct fastrpc_phy_page *pages;
-	u64 *fdlist;
-	int i, inbufs, outbufs, handles;
+	u64 *fdlist = ctx->fdlist;
+	int i, inbufs;
 	int ret = 0;
 
 	inbufs = REMOTE_SCALARS_INBUFS(ctx->sc);
-	outbufs = REMOTE_SCALARS_OUTBUFS(ctx->sc);
-	handles = REMOTE_SCALARS_INHANDLES(ctx->sc) + REMOTE_SCALARS_OUTHANDLES(ctx->sc);
-	list = fastrpc_invoke_buf_start(rpra, ctx->nscalars);
-	pages = fastrpc_phy_page_start(list, ctx->nscalars);
-	fdlist = (uint64_t *)(pages + inbufs + outbufs + handles);
 
 	for (i = inbufs; i < ctx->nbufs; ++i) {
 		if (!ctx->maps[i]) {
-- 
2.34.1

[PATCH v13 2/4] misc: fastrpc: Replace hardcoded ctxid mask with GENMASK

[Ekansh Gupta]

Replace the hardcoded context ID mask (0xFF0) with GENMASK(11, 4) to
improve readability and follow kernel bitfield conventions. Use
FIELD_PREP and FIELD_GET instead of manual shifts for setting and
extracting ctxid values.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
---
 drivers/misc/fastrpc.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 02c2765e1188..41c2ec0bc628 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -23,6 +23,7 @@
 #include <uapi/misc/fastrpc.h>
 #include <linux/of_reserved_mem.h>
 #include <linux/bits.h>
+#include <linux/bitops.h>
 
 #define ADSP_DOMAIN_ID (0)
 #define MDSP_DOMAIN_ID (1)
@@ -37,7 +38,7 @@
 #define FASTRPC_CTX_MAX (256)
 #define FASTRPC_INIT_HANDLE	1
 #define FASTRPC_DSP_UTILITIES_HANDLE	2
-#define FASTRPC_CTXID_MASK (0xFF0)
+#define FASTRPC_CTXID_MASK GENMASK(11, 4)
 #define INIT_FILELEN_MAX (2 * 1024 * 1024)
 #define INIT_FILE_NAMELEN_MAX (128)
 #define FASTRPC_DEVICE_NAME	"fastrpc"
@@ -566,7 +567,7 @@ static void fastrpc_context_free(struct kref *ref)
 	fastrpc_buf_free(ctx->buf);
 
 	spin_lock_irqsave(&cctx->lock, flags);
-	idr_remove(&cctx->ctx_idr, ctx->ctxid >> 4);
+	idr_remove(&cctx->ctx_idr, FIELD_GET(FASTRPC_CTXID_MASK, ctx->ctxid));
 	spin_unlock_irqrestore(&cctx->lock, flags);
 
 	kfree(ctx->maps);
@@ -704,7 +705,7 @@ static struct fastrpc_invoke_ctx *fastrpc_context_alloc(
 		spin_unlock_irqrestore(&cctx->lock, flags);
 		goto err_idr;
 	}
-	ctx->ctxid = ret << 4;
+	ctx->ctxid = FIELD_PREP(FASTRPC_CTXID_MASK, ret);
 	spin_unlock_irqrestore(&cctx->lock, flags);
 
 	kref_init(&ctx->refcount);
@@ -2547,7 +2548,7 @@ static int fastrpc_rpmsg_callback(struct rpmsg_device *rpdev, void *data,
 	if (!cctx)
 		return -ENODEV;
 
-	ctxid = ((rsp->ctx & FASTRPC_CTXID_MASK) >> 4);
+	ctxid = FIELD_GET(FASTRPC_CTXID_MASK, rsp->ctx);
 
 	spin_lock_irqsave(&cctx->lock, flags);
 	ctx = idr_find(&cctx->ctx_idr, ctxid);
-- 
2.34.1

[PATCH v13 3/4] misc: fastrpc: Expand context ID mask for DSP polling mode support

[Ekansh Gupta]

Current FastRPC context uses a 12-bit mask:
  [ID(8 bits)][PD type(4 bits)] = GENMASK(11, 4)

This works for normal calls but fails for DSP polling mode.
Polling mode expects a 16-bit layout:
  [15:8] = context ID (8 bits)
  [7:5]  = reserved
  [4]    = async mode bit
  [3:0]  = PD type (4 bits)

If async bit (bit 4) is set, DSP disables polling. With current
mask, odd IDs can set this bit, causing DSP to skip poll updates.

Update FASTRPC_CTXID_MASK to GENMASK(15, 8) so IDs occupy upper
byte and lower byte is left for DSP flags and PD type.

Reserved bits remain unused. This change is compatible with
polling mode and does not break non-polling behavior.

Bit layout:
  [15:8] = CCCCCCCC (context ID)
  [7:5]  = xxx (reserved)
  [4]    = A (async mode)
  [3:0]  = PPPP (PD type)

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
---
 drivers/misc/fastrpc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 41c2ec0bc628..78bd5b8f67f8 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -38,7 +38,7 @@
 #define FASTRPC_CTX_MAX (256)
 #define FASTRPC_INIT_HANDLE	1
 #define FASTRPC_DSP_UTILITIES_HANDLE	2
-#define FASTRPC_CTXID_MASK GENMASK(11, 4)
+#define FASTRPC_CTXID_MASK GENMASK(15, 8)
 #define INIT_FILELEN_MAX (2 * 1024 * 1024)
 #define INIT_FILE_NAMELEN_MAX (128)
 #define FASTRPC_DEVICE_NAME	"fastrpc"
-- 
2.34.1

[PATCH v13 4/4] misc: fastrpc: Add polling mode support for fastRPC driver

[Ekansh Gupta]

For any remote call to DSP, after sending an invocation message,
the fastRPC driver waits for a glink response, during which the CPU
can enter low power modes. This adds latency to the fastRPC call
due to CPU wakeup and scheduling overhead. Add polling mode support
where the fastRPC driver polls a shared memory location for
completion after sending the invocation, avoiding CPU wakeup and
scheduling latency and reducing fastRPC overhead. If the poll times
out, the call falls back to the normal interrupt/glink-based
completion path.

Poll mode is only applied to dynamic modules running in a user PD
(handle > FASTRPC_MAX_STATIC_HANDLE), since static/root-PD handles
are not expected to benefit from, or require, this optimization.
Support is advertised per SoC via fastrpc_soc_data, with a closed
exception list for older platforms whose DSP firmware is known to
support polling but which otherwise use the default soc_data.

Poll mode can be enabled by userspace via the FASTRPC_IOCTL_SET_OPTION
ioctl with the FASTRPC_POLL_MODE request id.

Since context IDs (ctxid) are allocated from a fixed-size, per-channel
cyclic IDR shared by all processes on a DSP, a context ID can be
recycled for a new request soon after it is freed. In poll mode the
context can be considered complete (and released) as soon as the poll
memory is updated, while the corresponding glink COMPLETE response
from the DSP may still be in flight. If that response arrives after
the ctxid has been reused, it would otherwise match the new context
and incorrectly signal completion for it while the DSP may still be
operating on the new context's buffers. To prevent this, embed a
monotonically increasing per-channel sequence number in the unused
upper bits of the ctxid/message context and validate it in the
rpmsg callback, dropping any response whose sequence number does not
match the current owner of that ctxid slot.

Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
---
 drivers/misc/fastrpc.c      | 194 ++++++++++++++++++++++++++++++++++--
 include/uapi/misc/fastrpc.h |  29 ++++++
 2 files changed, 215 insertions(+), 8 deletions(-)

diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 78bd5b8f67f8..94681394c1a0 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -24,6 +24,8 @@
 #include <linux/of_reserved_mem.h>
 #include <linux/bits.h>
 #include <linux/bitops.h>
+#include <linux/compiler.h>
+#include <linux/iopoll.h>
 
 #define ADSP_DOMAIN_ID (0)
 #define MDSP_DOMAIN_ID (1)
@@ -38,7 +40,16 @@
 #define FASTRPC_CTX_MAX (256)
 #define FASTRPC_INIT_HANDLE	1
 #define FASTRPC_DSP_UTILITIES_HANDLE	2
+/*
+ * Maximum handle value for static handles.
+ * Static handles are pre-defined, fixed numeric values statically assigned
+ * in the IDL file or FastRPC framework.
+ */
+#define FASTRPC_MAX_STATIC_HANDLE (20)
 #define FASTRPC_CTXID_MASK GENMASK(15, 8)
+/* 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)
 #define INIT_FILELEN_MAX (2 * 1024 * 1024)
 #define INIT_FILE_NAMELEN_MAX (128)
 #define FASTRPC_DEVICE_NAME	"fastrpc"
@@ -106,6 +117,12 @@
 
 #define miscdev_to_fdevice(d) container_of(d, struct fastrpc_device, miscdev)
 
+/* Poll response number from remote processor for call completion */
+#define FASTRPC_POLL_RESPONSE (0xdecaf)
+
+/* Polling mode timeout limit */
+#define FASTRPC_POLL_MAX_TIMEOUT_US (10000)
+
 struct fastrpc_phy_page {
 	dma_addr_t addr;	/* dma address */
 	u64 size;		/* size of contiguous region */
@@ -236,8 +253,14 @@ struct fastrpc_invoke_ctx {
 	u32 sc;
 	u64 *fdlist;
 	u32 *crc;
+	/* Poll memory that DSP updates */
+	u32 *poll_addr;
 	u64 ctxid;
 	u64 msg_sz;
+	/* work done status flag */
+	bool is_work_done;
+	/* process updates poll memory instead of glink response */
+	bool is_polled;
 	struct kref refcount;
 	struct list_head node; /* list of ctxs */
 	struct completion work;
@@ -263,6 +286,7 @@ struct fastrpc_soc_data {
 	u32 sid_pos;
 	u32 dma_addr_bits_cdsp;
 	u32 dma_addr_bits_default;
+	bool poll_mode_supported;
 };
 
 struct fastrpc_channel_ctx {
@@ -285,6 +309,9 @@ struct fastrpc_channel_ctx {
 	struct list_head invoke_interrupted_mmaps;
 	bool secure;
 	bool unsigned_support;
+	bool poll_mode_supported;
+	/* Per-channel sequence counter; incremented on every context allocation */
+	atomic_t ctx_seq;
 	u64 dma_mask;
 	const struct fastrpc_soc_data *soc_data;
 };
@@ -308,6 +335,8 @@ struct fastrpc_user {
 	int client_id;
 	int pd;
 	bool is_secure_dev;
+	/* Flags poll mode state */
+	bool poll_mode;
 	/* Lock for lists */
 	spinlock_t lock;
 	/* lock for allocations */
@@ -705,7 +734,9 @@ static struct fastrpc_invoke_ctx *fastrpc_context_alloc(
 		spin_unlock_irqrestore(&cctx->lock, flags);
 		goto err_idr;
 	}
-	ctx->ctxid = FIELD_PREP(FASTRPC_CTXID_MASK, ret);
+	ctx->ctxid = FIELD_PREP(FASTRPC_CTXID_MASK, ret) |
+		     FIELD_PREP(FASTRPC_CTXID_SEQ_MASK,
+				(u64)atomic_inc_return(&cctx->ctx_seq));
 	spin_unlock_irqrestore(&cctx->lock, flags);
 
 	kref_init(&ctx->refcount);
@@ -970,7 +1001,8 @@ static int fastrpc_get_meta_size(struct fastrpc_invoke_ctx *ctx)
 		sizeof(struct fastrpc_invoke_buf) +
 		sizeof(struct fastrpc_phy_page)) * ctx->nscalars +
 		sizeof(u64) * FASTRPC_MAX_FDLIST +
-		sizeof(u32) * FASTRPC_MAX_CRCLIST;
+		sizeof(u32) * FASTRPC_MAX_CRCLIST +
+		sizeof(u32);
 
 	return size;
 }
@@ -1066,6 +1098,9 @@ static int fastrpc_get_args(u32 kernel, struct fastrpc_invoke_ctx *ctx)
 	list = fastrpc_invoke_buf_start(rpra, ctx->nscalars);
 	pages = fastrpc_phy_page_start(list, ctx->nscalars);
 	ctx->fdlist = (u64 *)(pages + ctx->nscalars);
+	ctx->poll_addr = (u32 *)((uintptr_t)ctx->fdlist + sizeof(u64) * FASTRPC_MAX_FDLIST +
+			     sizeof(u32) * FASTRPC_MAX_CRCLIST);
+
 	args = (uintptr_t)ctx->buf->virt + metalen;
 	rlen = pkt_size - metalen;
 	ctx->rpra = rpra;
@@ -1235,6 +1270,71 @@ static int fastrpc_invoke_send(struct fastrpc_session_ctx *sctx,
 
 }
 
+static u32 fastrpc_read_poll_addr(struct fastrpc_invoke_ctx *ctx)
+{
+	dma_rmb();
+	return READ_ONCE(*ctx->poll_addr);
+}
+
+static int poll_for_remote_response(struct fastrpc_invoke_ctx *ctx)
+{
+	u32 val;
+	int ret;
+
+	/*
+	 * Poll until DSP writes FASTRPC_POLL_RESPONSE into *ctx->poll_addr
+	 * or until another path marks the work done.
+	 */
+	ret = read_poll_timeout_atomic(fastrpc_read_poll_addr, val,
+				       (val == FASTRPC_POLL_RESPONSE) || ctx->is_work_done, 1,
+				       FASTRPC_POLL_MAX_TIMEOUT_US, false, ctx);
+
+	if (!ret && val == FASTRPC_POLL_RESPONSE) {
+		/*
+		 * DSP writes FASTRPC_POLL_RESPONSE to signal successful
+		 * completion via the poll path.
+		 */
+		ctx->is_work_done = true;
+		ctx->retval = 0;
+	}
+
+	if (ret == -ETIMEDOUT)
+		ret = -EIO;
+
+	return ret;
+}
+
+static inline int fastrpc_wait_for_response(struct fastrpc_invoke_ctx *ctx,
+					    u32 kernel)
+{
+	int err = 0;
+
+	if (kernel) {
+		if (!wait_for_completion_timeout(&ctx->work, 10 * HZ))
+			err = -ETIMEDOUT;
+	} else {
+		err = wait_for_completion_interruptible(&ctx->work);
+	}
+
+	return err;
+}
+
+static int fastrpc_wait_for_completion(struct fastrpc_invoke_ctx *ctx,
+				       u32 kernel)
+{
+	int err;
+
+	if (ctx->is_polled) {
+		err = poll_for_remote_response(ctx);
+		if (!err)
+			return 0;
+		/* If polling timed out or failed, move to normal response mode */
+		ctx->is_polled = false;
+	}
+
+	return fastrpc_wait_for_response(ctx, kernel);
+}
+
 static int fastrpc_internal_invoke(struct fastrpc_user *fl,  u32 kernel,
 				   u32 handle, u32 sc,
 				   struct fastrpc_invoke_args *args)
@@ -1270,13 +1370,14 @@ static int fastrpc_internal_invoke(struct fastrpc_user *fl,  u32 kernel,
 	if (err)
 		goto bail;
 
-	if (kernel) {
-		if (!wait_for_completion_timeout(&ctx->work, 10 * HZ))
-			err = -ETIMEDOUT;
-	} else {
-		err = wait_for_completion_interruptible(&ctx->work);
-	}
+	/*
+	 * Set message context as polled if the call is for a user PD
+	 * dynamic module and user has enabled poll mode.
+	 */
+	if (handle > FASTRPC_MAX_STATIC_HANDLE && fl->pd == USER_PD && fl->poll_mode)
+		ctx->is_polled = true;
 
+	err = fastrpc_wait_for_completion(ctx, kernel);
 	if (err)
 		goto bail;
 
@@ -1842,6 +1943,35 @@ static int fastrpc_get_info_from_kernel(struct fastrpc_ioctl_capability *cap,
 	return 0;
 }
 
+static int fastrpc_set_option(struct fastrpc_user *fl, char __user *argp)
+{
+	struct fastrpc_ioctl_set_option opt = {0};
+	int i;
+
+	if (copy_from_user(&opt, argp, sizeof(opt)))
+		return -EFAULT;
+
+	for (i = 0; i < ARRAY_SIZE(opt.reserved); i++) {
+		if (opt.reserved[i] != 0)
+			return -EINVAL;
+	}
+
+	if (opt.request_id != FASTRPC_POLL_MODE)
+		return -EINVAL;
+
+	if (!fl->cctx->poll_mode_supported)
+		return -EOPNOTSUPP;
+
+	if (opt.value == FASTRPC_POLL_MODE_ENABLE)
+		fl->poll_mode = true;
+	else if (opt.value == FASTRPC_POLL_MODE_DISABLE)
+		fl->poll_mode = false;
+	else
+		return -EINVAL;
+
+	return 0;
+}
+
 static int fastrpc_get_dsp_info(struct fastrpc_user *fl, char __user *argp)
 {
 	struct fastrpc_ioctl_capability cap = {0};
@@ -2203,6 +2333,9 @@ static long fastrpc_device_ioctl(struct file *file, unsigned int cmd,
 	case FASTRPC_IOCTL_MEM_UNMAP:
 		err = fastrpc_req_mem_unmap(fl, argp);
 		break;
+	case FASTRPC_IOCTL_SET_OPTION:
+		err = fastrpc_set_option(fl, argp);
+		break;
 	case FASTRPC_IOCTL_GET_DSP_INFO:
 		err = fastrpc_get_dsp_info(fl, argp);
 		break;
@@ -2359,6 +2492,7 @@ static const struct fastrpc_soc_data kaanapali_soc_data = {
 	.sid_pos = 56,
 	.dma_addr_bits_cdsp = 34,
 	.dma_addr_bits_default = 32,
+	.poll_mode_supported = true,
 };
 
 static const struct fastrpc_soc_data default_soc_data = {
@@ -2367,6 +2501,29 @@ static const struct fastrpc_soc_data default_soc_data = {
 	.dma_addr_bits_default = 32,
 };
 
+/*
+ * Exception list for older platforms that use default_soc_data but whose
+ * DSP firmware supports FastRPC polling mode.
+ *
+ * NOTE: This list is intentionally closed.
+ * Do NOT add new platforms here. New SoCs must advertise polling mode
+ * support via their soc_data.
+ */
+
+static const struct of_device_id fastrpc_poll_supported_machines[] __maybe_unused = {
+	{ .compatible = "qcom,milos" },
+	{ .compatible = "qcom,qcs8300" },
+	{ .compatible = "qcom,sa8775p" },
+	{ .compatible = "qcom,sar2130p" },
+	{ .compatible = "qcom,sm8450" },
+	{ .compatible = "qcom,sm8550" },
+	{ .compatible = "qcom,sm8650" },
+	{ .compatible = "qcom,sm8750" },
+	{ .compatible = "qcom,x1e80100" },
+	{ .compatible = "qcom,x1p42100" },
+	{},
+};
+
 static int fastrpc_rpmsg_probe(struct rpmsg_device *rpdev)
 {
 	struct device *rdev = &rpdev->dev;
@@ -2433,6 +2590,8 @@ static int fastrpc_rpmsg_probe(struct rpmsg_device *rpdev)
 	secure_dsp = !(of_property_read_bool(rdev->of_node, "qcom,non-secure-domain"));
 	data->secure = secure_dsp;
 	data->soc_data = soc_data;
+	data->poll_mode_supported = soc_data->poll_mode_supported ||
+		of_machine_get_match(fastrpc_poll_supported_machines);
 
 	switch (domain_id) {
 	case ADSP_DOMAIN_ID:
@@ -2462,6 +2621,7 @@ static int fastrpc_rpmsg_probe(struct rpmsg_device *rpdev)
 	}
 
 	kref_init(&data->refcount);
+	atomic_set(&data->ctx_seq, 0);
 
 	rdev->dma_mask = &data->dma_mask;
 	dma_set_mask_and_coherent(rdev, DMA_BIT_MASK(32));
@@ -2559,7 +2719,25 @@ static int fastrpc_rpmsg_callback(struct rpmsg_device *rpdev, void *data,
 		return -ENOENT;
 	}
 
+	/*
+	 * Validate the sequence number embedded in the upper bits of the
+	 * context ID.  Under high concurrency the IDR slot can be recycled
+	 * for a new request before a late (or duplicate) glink COMPLETE
+	 * response for the previous request arrives.  Without this check the
+	 * driver would call complete() on the wrong context, waking a thread
+	 * whose buffers are still being accessed by the DSP.
+	 */
+	if (FIELD_GET(FASTRPC_CTXID_SEQ_MASK, rsp->ctx) !=
+	    FIELD_GET(FASTRPC_CTXID_SEQ_MASK, ctx->ctxid)) {
+		dev_dbg(&rpdev->dev,
+			"Stale glink response ctx 0x%llx (expected seq 0x%llx), dropping\n",
+			rsp->ctx,
+			FIELD_GET(FASTRPC_CTXID_SEQ_MASK, ctx->ctxid));
+		return 0;
+	}
+
 	ctx->retval = rsp->retval;
+	ctx->is_work_done = true;
 	complete(&ctx->work);
 
 	/*
diff --git a/include/uapi/misc/fastrpc.h b/include/uapi/misc/fastrpc.h
index c6e2925f47e6..ba1ea5ed426c 100644
--- a/include/uapi/misc/fastrpc.h
+++ b/include/uapi/misc/fastrpc.h
@@ -16,6 +16,7 @@
 #define FASTRPC_IOCTL_INIT_CREATE_STATIC _IOWR('R', 9, struct fastrpc_init_create_static)
 #define FASTRPC_IOCTL_MEM_MAP		_IOWR('R', 10, struct fastrpc_mem_map)
 #define FASTRPC_IOCTL_MEM_UNMAP		_IOWR('R', 11, struct fastrpc_mem_unmap)
+#define FASTRPC_IOCTL_SET_OPTION	_IOWR('R', 12, struct fastrpc_ioctl_set_option)
 #define FASTRPC_IOCTL_GET_DSP_INFO	_IOWR('R', 13, struct fastrpc_ioctl_capability)
 
 /**
@@ -67,6 +68,28 @@ enum fastrpc_proc_attr {
 /* Fastrpc attribute for memory protection of buffers */
 #define FASTRPC_ATTR_SECUREMAP	(1)
 
+/**
+ * FASTRPC_POLL_MODE - Enable/disable poll mode for FastRPC invocations
+ *
+ * Poll mode is an optimization that allows the CPU to poll shared memory
+ * for completion instead of waiting for an interrupt-based response.
+ * This reduces latency for fast-completing operations.
+ *
+ * Restrictions:
+ * - Only supported for USER_PD (User Protection Domain)
+ * - Only applies to dynamic modules (handle > 20)
+ * - Static modules always use interrupt-based completion
+ *
+ * Values:
+ * - 0: Disable poll mode (use interrupt-based completion)
+ * - 1: Enable poll mode (poll shared memory for completion)
+ */
+#define FASTRPC_POLL_MODE	(1)
+
+/* Values for FASTRPC_POLL_MODE request */
+#define FASTRPC_POLL_MODE_DISABLE	0
+#define FASTRPC_POLL_MODE_ENABLE	1
+
 struct fastrpc_invoke_args {
 	__u64 ptr;
 	__u64 length;
@@ -133,6 +156,12 @@ struct fastrpc_mem_unmap {
 	__s32 reserved[5];
 };
 
+struct fastrpc_ioctl_set_option {
+	__u32 request_id;	/* Request type (e.g., FASTRPC_POLL_MODE) */
+	__u32 value;	/* Request-specific value */
+	__s32 reserved[6];
+};
+
 struct fastrpc_ioctl_capability {
 	__u32 unused; /* deprecated, ignored by the kernel */
 	__u32 attribute_id;
-- 
2.34.1

Re: [PATCH v13 1/4] misc: fastrpc: Move fdlist to invoke context structure

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Arbitrary kernel memory read to userspace via untrusted `rpra` pointers.
- [Critical] Use-After-Free via DSP-manipulated `fdlist` dropping active map references.
- [Medium] Memory leak of `fastrpc_map` objects on timeout or interruption.
--

--- Patch [1]: [PATCH v13 1/4] misc: fastrpc: Move fdlist to invoke context structure ---
commit 3273bebbc8c035be416508d67400b312f049c6e6
Author: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>

misc: fastrpc: Move fdlist to invoke context structure

This commit moves the fdlist from being recalculated during
fastrpc_put_args() to being stored directly in the fastrpc_invoke_ctx
structure. This centralizes its handling and simplifies the meta buffer
preparation and reading logic.

> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> index d86e79134c681..02c2765e1188c 100644
> --- a/drivers/misc/fastrpc.c
> +++ b/drivers/misc/fastrpc.c

[ ... ]

> @@ -1165,18 +1167,11 @@ static int fastrpc_put_args(struct fastrpc_invoke_ctx *ctx,
>  	union fastrpc_remote_arg *rpra = ctx->rpra;
>  	struct fastrpc_user *fl = ctx->fl;
>  	struct fastrpc_map *mmap = NULL;
> -	struct fastrpc_invoke_buf *list;
> -	struct fastrpc_phy_page *pages;
> -	u64 *fdlist;
> -	int i, inbufs, outbufs, handles;
> +	u64 *fdlist = ctx->fdlist;
> +	int i, inbufs;
>  	int ret = 0;
>  
>  	inbufs = REMOTE_SCALARS_INBUFS(ctx->sc);
> -	outbufs = REMOTE_SCALARS_OUTBUFS(ctx->sc);
> -	handles = REMOTE_SCALARS_INHANDLES(ctx->sc) + REMOTE_SCALARS_OUTHANDLES(ctx->sc);
> -	list = fastrpc_invoke_buf_start(rpra, ctx->nscalars);
> -	pages = fastrpc_phy_page_start(list, ctx->nscalars);
> -	fdlist = (uint64_t *)(pages + inbufs + outbufs + handles);
>  
>  	for (i = inbufs; i < ctx->nbufs; ++i) {
>  		if (!ctx->maps[i]) {

[Severity: Medium]
This is a pre-existing issue, but does this code leak the fastrpc_map
objects if an invoke operation times out or is interrupted?

If fastrpc_internal_invoke() exits early for timeouts or signals, it skips
fastrpc_put_args() and leaves the context in the pending list:

drivers/misc/fastrpc.c:fastrpc_internal_invoke() {
    ...
    if (err != -ERESTARTSYS && err != -ETIMEDOUT) {
        /* We are done with this compute context */
        spin_lock(&fl->lock);
        list_del(&ctx->node);
        spin_unlock(&fl->lock);
        fastrpc_context_put(ctx);
    }
    ...
}

When the DSP eventually replies, the completion callback asynchronously frees
the context via fastrpc_context_free(). However, fastrpc_context_free() does
not execute the fdlist cleanup logic:

drivers/misc/fastrpc.c:fastrpc_context_free() {
    ...
    for (i = 0; i < ctx->nbufs; i++)
        fastrpc_map_put(ctx->maps[i]);
    ...
}

Are maps the DSP returned in fdlist to be released permanently leaked in this
scenario?

[Severity: Critical]
This is a pre-existing issue, but can a compromised DSP cause a
use-after-free by manipulating the untrusted fdlist?

In fastrpc_put_args(), the kernel iterates over fdlist and drops references
for maps without verifying if they are actively in use by the current
context:

drivers/misc/fastrpc.c:fastrpc_put_args() {
    ...
    for (i = 0; i < FASTRPC_MAX_FDLIST; i++) {
        if (!fdlist[i])
            break;
        if (!fastrpc_map_lookup(fl, (int)fdlist[i], &mmap, false))
            fastrpc_map_put(mmap);
    }
    ...
}

If a malicious DSP injects file descriptors of actively used maps (e.g.,
those in ctx->maps[i]), it could cause their reference count to drop to zero
prematurely. When the context is subsequently destroyed, the kernel drops
references again:

drivers/misc/fastrpc.c:fastrpc_context_free() {
    ...
    for (i = 0; i < ctx->nbufs; i++)
        fastrpc_map_put(ctx->maps[i]);
    ...
}

Could this lead to memory corruption when ctx->maps[i] is freed twice?

[Severity: Critical]
This is a pre-existing issue, but does this code allow arbitrary kernel memory
disclosure via untrusted rpra pointers?

The rpra array resides within ctx->buf->virt, a DMA-mapped buffer accessible
by the DSP. In fastrpc_put_args(), the kernel blindly reads the source pointer
and length directly from this shared memory:

drivers/misc/fastrpc.c:fastrpc_put_args() {
    ...
            void *src = (void *)(uintptr_t)rpra[i].buf.pv;
            void *dst = (void *)(uintptr_t)ctx->args[i].ptr;
            u64 len = rpra[i].buf.len;

            if (!kernel) {
                if (copy_to_user((void __user *)dst, src, len)) {
    ...
}

If a compromised DSP manipulates rpra[i].buf.pv and rpra[i].buf.len to point
to arbitrary kernel addresses, will the kernel pass these directly to
copy_to_user(), leaking sensitive data to userspace?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260713052236.3033744-1-ekansh.gupta@oss.qualcomm.com?part=1

Re: [PATCH v13 3/4] misc: fastrpc: Expand context ID mask for DSP polling mode support

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:

Pre-existing issues:
- [High] Circular reference between fastrpc_user and fastrpc_invoke_ctx leads to permanent memory leak on interrupted invokes
- [High] IDR lookup without reference count acquisition in fastrpc_rpmsg_callback leads to Use-After-Free
- [High] DMA buffers moved to invoke_interrupted_mmaps are permanently leaked
- [High] DSP's reference count on fastrpc_invoke_ctx is never dropped during rpmsg device removal
- [High] fastrpc_invoke_ctx is exposed to IDR before its refcount is initialized
--

--- Patch [3]: [PATCH v13 3/4] misc: fastrpc: Expand context ID mask for DSP polling mode support ---
commit 3f54bd616159b6758a0a91f71a64fbcdf225579a
Author: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>

misc: fastrpc: Expand context ID mask for DSP polling mode support

Current FastRPC context uses a 12-bit mask for context ID and PD type.
This expands it to a 16-bit layout for DSP polling mode support, ensuring
the async mode bit doesn't overlap with odd context IDs.

> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> index 41c2ec0bc6281..78bd5b8f67f85 100644
> --- a/drivers/misc/fastrpc.c
> +++ b/drivers/misc/fastrpc.c
> @@ -38,7 +38,7 @@
>  #define FASTRPC_CTX_MAX (256)
>  #define FASTRPC_INIT_HANDLE	1
>  #define FASTRPC_DSP_UTILITIES_HANDLE	2
> -#define FASTRPC_CTXID_MASK GENMASK(11, 4)
> +#define FASTRPC_CTXID_MASK GENMASK(15, 8)

[Severity: High]
This isn't a bug introduced by this patch, but seeing the context ID mask
update prompted me to look at how the IDR handles contexts, and I noticed a
potential circular reference.

Looking at fastrpc_internal_invoke(), if an RPC invoke is interrupted
(-ERESTARTSYS) or times out, it skips dropping the context's initial reference
and leaves it in fl->pending indefinitely:

drivers/misc/fastrpc.c:fastrpc_internal_invoke() {
    ...
    if (err == -ERESTARTSYS) {
    ...
}

However, ctx holds a strong reference to the fastrpc_user object (fl) created
in fastrpc_context_alloc():

drivers/misc/fastrpc.c:fastrpc_context_alloc() {
    ...
    /* Take a reference to user, released in fastrpc_context_free() */
    fastrpc_user_get(user);
    ...
}

Does this create a circular reference where fl's refcount can never reach 0,
meaning fastrpc_user_free() is never called to clean up the abandoned contexts?

Can this be triggered by userspace sending a signal to a waiting thread?

[Severity: High]
This is a pre-existing issue, but I also noticed a potential Use-After-Free
race condition regarding the context IDR.

In fastrpc_rpmsg_callback(), the context is retrieved without acquiring a
reference count (e.g., using kref_get_unless_zero) before dropping the lock:

drivers/misc/fastrpc.c:fastrpc_rpmsg_callback() {
    ...
    spin_lock_irqsave(&cctx->lock, flags);
    ctx = idr_find(&cctx->ctx_idr, ctxid);
    spin_unlock_irqrestore(&cctx->lock, flags);
    ...
}

If the context's refcount concurrently reaches zero, fastrpc_context_free() is
called, but the object is removed from the IDR relatively late, after freeing
buffers:

drivers/misc/fastrpc.c:fastrpc_context_free() {
    ...
    spin_lock_irqsave(&cctx->lock, flags);
    idr_remove(&cctx->ctx_idr, FIELD_GET(FASTRPC_CTXID_MASK, ctx->ctxid));
    spin_unlock_irqrestore(&cctx->lock, flags);
    ...
}

Is there a wide race window here where a duplicate or delayed DSP response
could find the context in the IDR, and then write to ctx->retval or schedule a
work item on the freed object?

[Severity: High]
This isn't a bug introduced by this patch, but do the DMA buffers moved to
invoke_interrupted_mmaps get permanently leaked?

When fastrpc_internal_invoke() is interrupted by a signal, buffers are moved
to the interrupted list:

drivers/misc/fastrpc.c:fastrpc_internal_invoke() {
    ...
            list_add_tail(&buf->node, &fl->cctx->invoke_interrupted_mmaps);
    ...
}

But when the DSP channel is closed or crashes, fastrpc_rpmsg_remove() iterates
over this list and removes the nodes without calling fastrpc_buf_free():

drivers/misc/fastrpc.c:fastrpc_rpmsg_remove() {
    ...
    list_for_each_entry_safe(buf, b, &cctx->invoke_interrupted_mmaps, node)
        list_del(&buf->node);
    ...
}

Are these memory map buffers deliberately dropped, or is this leaking the
underlying kernel DMA memory?

[Severity: High]
This is a pre-existing issue, but is the DSP's outstanding reference count on
fastrpc_invoke_ctx ever dropped during rpmsg device removal?

If the DSP crashes and fastrpc_rpmsg_remove() runs, it unblocks waiting threads
by setting -EPIPE and signaling completions:

drivers/misc/fastrpc.c:fastrpc_notify_users() {
    ...
        ctx->retval = -EPIPE;
        complete(&ctx->work);
    ...
}

Previously, fastrpc_invoke_send() acquired a strong reference on ctx on
behalf of the DSP, which is normally dropped by fastrpc_rpmsg_callback() when
the DSP replies.

Does setting the completion here without dropping that reference leave the
contexts with a non-zero refcount forever?

[Severity: High]
This isn't a bug introduced by this patch, but could fastrpc_invoke_ctx be
exposed to the IDR before its refcount is initialized?

In fastrpc_context_alloc(), the ctx is inserted into the IDR and the lock is
dropped before initializing the refcount:

drivers/misc/fastrpc.c:fastrpc_context_alloc() {
    ...
    spin_unlock_irqrestore(&cctx->lock, flags);

    kref_init(&ctx->refcount);
    ...
}

Could a compromised DSP send a duplicate response matching this newly recycled
ID, triggering fastrpc_rpmsg_callback() to look up the ID, schedule put_work,
and decrement the uninitialized zero refcount (from kzalloc) before the
allocation thread initializes it to 1?

>  #define INIT_FILELEN_MAX (2 * 1024 * 1024)
>  #define INIT_FILE_NAMELEN_MAX (128)
>  #define FASTRPC_DEVICE_NAME	"fastrpc"

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260713052236.3033744-1-ekansh.gupta@oss.qualcomm.com?part=3

Re: [PATCH v13 2/4] misc: fastrpc: Replace hardcoded ctxid mask with GENMASK

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:

New issues:
- [Low] The patch uses `FIELD_PREP` and `FIELD_GET` macros which are defined in `<linux/bitfield.h>`, but incorrectly includes `<linux/bitops.h>` instead.

Pre-existing issues:
- [Critical] Circular reference in `fastrpc_internal_invoke` leaks contexts, DMA memory, and IDR slots on `-ERESTARTSYS`, leading to a system-wide Denial of Service.
- [High] Failure in `copy_to_user` during `fastrpc_req_mmap` leaves a freed buffer on the `fl->mmaps` list.
- [High] Concurrent allocations of `fl->cctx->remote_heap` lack locking, leading to UAF and memory leaks.
- [High] fastrpc_rpmsg_callback dereferences ctx without taking a reference, leading to a race condition and UAF.
--

--- Patch [2]: [PATCH v13 2/4] misc: fastrpc: Replace hardcoded ctxid mask with GENMASK ---
commit e84380d211cbe45ae646449f6efb6a5a3e342fcc
Author: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>

misc: fastrpc: Replace hardcoded ctxid mask with GENMASK

The commit replaces the hardcoded 0xFF0 mask with GENMASK(11, 4) for context
ID extraction to follow bitfield conventions. It uses FIELD_PREP and FIELD_GET
macros instead of manual shifts.

> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> index 02c2765e1188c..41c2ec0bc6281 100644
> --- a/drivers/misc/fastrpc.c
> +++ b/drivers/misc/fastrpc.c
> @@ -23,6 +23,7 @@
>  #include <uapi/misc/fastrpc.h>
>  #include <linux/of_reserved_mem.h>
>  #include <linux/bits.h>
> +#include <linux/bitops.h>

[Severity: Low]
Should this code include <linux/bitfield.h> instead of <linux/bitops.h>?

The FIELD_PREP and FIELD_GET macros are defined in <linux/bitfield.h>. Not
including the proper header may cause compilation failures on architectures
that do not transitively include it.

[ ... ]

> @@ -2547,7 +2548,7 @@ static int fastrpc_rpmsg_callback(struct rpmsg_device *rpdev, void *data,
>  	if (!cctx)
>  		return -ENODEV;
>  
> -	ctxid = ((rsp->ctx & FASTRPC_CTXID_MASK) >> 4);
> +	ctxid = FIELD_GET(FASTRPC_CTXID_MASK, rsp->ctx);
>  
>  	spin_lock_irqsave(&cctx->lock, flags);
>  	ctx = idr_find(&cctx->ctx_idr, ctxid);

[Severity: High]
This isn't a bug introduced by this patch, but could fastrpc_rpmsg_callback() 
dereference ctx without taking a reference here?

If a duplicate or late response is received, the first reply schedules
ctx->put_work which invokes fastrpc_context_free(). If a second reply's
IDR lookup occurs right before fastrpc_context_free() removes it from the
IDR, it might yield a pointer that gets freed immediately after the lock
is dropped:

drivers/misc/fastrpc.c:fastrpc_rpmsg_callback() {
    ...
	spin_lock_irqsave(&cctx->lock, flags);
	ctx = idr_find(&cctx->ctx_idr, ctxid);
	spin_unlock_irqrestore(&cctx->lock, flags);

	if (!ctx) {
		dev_err(&rpdev->dev, "No context ID matches response\n");
		return -ENOENT;
	}

	ctx->retval = rsp->retval;
	complete(&ctx->work);
    ...
}

Writing to ctx->retval and calling complete() would then operate on freed memory.
Should kref_get_unless_zero() be used before dropping the lock?

[ ... ]

[Severity: Critical]
This isn't a bug introduced by this patch, but is there a circular reference
regression on -ERESTARTSYS in fastrpc_internal_invoke()?

drivers/misc/fastrpc.c:fastrpc_internal_invoke() {
    ...
	if (kernel) {
		if (!wait_for_completion_timeout(&ctx->work, 10 * HZ))
			err = -ETIMEDOUT;
	} else {
		err = wait_for_completion_interruptible(&ctx->work);
	}

	if (err)
		goto bail;
    ...
bail:
	if (err != -ERESTARTSYS && err != -ETIMEDOUT) {
		/* We are done with this compute context */
		spin_lock(&fl->lock);
		list_del(&ctx->node);
		spin_unlock(&fl->lock);
		fastrpc_context_put(ctx);
	}
    ...
}

If a user interrupts FASTRPC_IOCTL_INVOKE with a signal, err becomes 
-ERESTARTSYS. The context is left on fl->pending without calling
fastrpc_context_put(ctx). Since ctx holds a reference to fl, fl->refcount
will never reach 0 on device close, permanently leaking contexts and DMA
memory. Can this be used to exhaust IDR slots?

[ ... ]

[Severity: High]
This isn't a bug introduced by this patch, but what happens in
fastrpc_req_mmap() if copy_to_user() fails after the buffer is added to
fl->mmaps?

drivers/misc/fastrpc.c:fastrpc_req_mmap() {
    ...
	spin_lock(&fl->lock);
	list_add_tail(&buf->node, &fl->mmaps);
	spin_unlock(&fl->lock);

	if (copy_to_user((void __user *)argp, &req, sizeof(req))) {
		err = -EFAULT;
		goto err_assign;
	}
    ...
err_assign:
	fastrpc_req_munmap_impl(fl, buf);

	return err;
}

The fastrpc_req_munmap_impl() function frees the buffer, but it remains linked
on fl->mmaps. When the user closes the device, fastrpc_user_free() iterates
over fl->mmaps and could double-free this buffer. Should the buffer be removed
from the list before returning?

[ ... ]

[Severity: High]
This isn't a bug introduced by this patch, but are concurrent allocations of
remote_heap safely handled in fastrpc_init_create_static_process()?

drivers/misc/fastrpc.c:fastrpc_init_create_static_process() {
    ...
	if (!fl->cctx->remote_heap) {
		err = fastrpc_remote_heap_alloc(fl, fl->sctx->dev, init.memlen,
						&fl->cctx->remote_heap);
		if (err)
			goto err_name;
    ...
}

If two threads concurrently call FASTRPC_IOCTL_INIT_CREATE_STATIC, both might 
observe !fl->cctx->remote_heap as true and call fastrpc_remote_heap_alloc(), 
overwriting the shared pointer and leaking the first allocation. Could this 
also lead to a use-after-free if one thread branches to err_map and frees 
fl->cctx->remote_heap while the other thread is using it?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260713052236.3033744-1-ekansh.gupta@oss.qualcomm.com?part=2

Re: [PATCH v13 4/4] misc: fastrpc: Add polling mode support for fastRPC driver

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

New issues:
- [Critical] Unprivileged Denial of Service via IDR slot exhaustion and memory leaks in polling mode.
- [High] Data race on `ctx->is_work_done` and `ctx->retval` due to missing memory barriers.

Pre-existing issues:
- [Critical] Duplicate Glink completion responses bypass sequence validation and cause a Use-After-Free.
- [High] Accessing `ctx->ctxid` outside the IDR lock leads to a Use-After-Free.
--

--- Patch [4]: [PATCH v13 4/4] misc: fastrpc: Add polling mode support for fastRPC driver ---
commit d9afeb4ebcb604d7e06c0448d2aa66154de980d6
Author: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>

misc: fastrpc: Add polling mode support for fastRPC driver

This commit adds polling mode support for the fastRPC driver to avoid
CPU wakeup and scheduling overhead during glink responses. It polls a
shared memory location for completion after sending the invocation.
It also embeds a sequence number in the context ID to prevent recycling
issues.

> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> --- a/drivers/misc/fastrpc.c
> +++ b/drivers/misc/fastrpc.c
[ ... ]
> +static int poll_for_remote_response(struct fastrpc_invoke_ctx *ctx)
> +{
> +	u32 val;
> +	int ret;
> +
> +	/*
> +	 * Poll until DSP writes FASTRPC_POLL_RESPONSE into *ctx->poll_addr
> +	 * or until another path marks the work done.
> +	 */
> +	ret = read_poll_timeout_atomic(fastrpc_read_poll_addr, val,
> +				       (val == FASTRPC_POLL_RESPONSE) || ctx->is_work_done, 1,

[Severity: High]
Are there missing memory barriers when updating these fields?

When the Glink response arrives, fastrpc_rpmsg_callback() updates ctx->retval
and then sets ctx->is_work_done = true. Because there are no write memory
barriers, the CPU or compiler can reorder these stores.

Concurrently, poll_for_remote_response() spins reading ctx->is_work_done
without a read barrier. If the polling thread observes is_work_done == true
before the retval update is visible, could it break the loop and read the
stale initial value of ctx->retval (-1), causing the invocation to incorrectly
fail?

[ ... ]
> +static int fastrpc_wait_for_completion(struct fastrpc_invoke_ctx *ctx,
> +				       u32 kernel)
> +{
> +	int err;
> +
> +	if (ctx->is_polled) {
> +		err = poll_for_remote_response(ctx);
> +		if (!err)
> +			return 0;

[Severity: Critical]
Does returning early on polling success lead to IDR slot exhaustion and memory
leaks?

If a userspace process invokes a DSP module in polling mode, the DSP updates
the poll memory but might maliciously omit the Glink completion response. The
CPU thread completes the polling successfully, returns to userspace, and
deletes the context from user->pending in fastrpc_internal_invoke().

Because the Glink callback never runs, the context's reference count never
reaches zero, and it appears to be permanently abandoned in the IDR. Could an
unprivileged process loop this to quickly exhaust the 256 FASTRPC_CTX_MAX IDR
slots?

[ ... ]
> @@ -2559,7 +2719,25 @@ static int fastrpc_rpmsg_callback(struct rpmsg_device *rpdev, void *data,
>  		return -ENOENT;
>  	}
>  
> +	/*
> +	 * Validate the sequence number embedded in the upper bits of the
> +	 * context ID.  Under high concurrency the IDR slot can be recycled
> +	 * for a new request before a late (or duplicate) glink COMPLETE
> +	 * response for the previous request arrives.  Without this check the
> +	 * driver would call complete() on the wrong context, waking a thread
> +	 * whose buffers are still being accessed by the DSP.
> +	 */
> +	if (FIELD_GET(FASTRPC_CTXID_SEQ_MASK, rsp->ctx) !=
> +	    FIELD_GET(FASTRPC_CTXID_SEQ_MASK, ctx->ctxid)) {

[Severity: High]
This isn't a bug introduced by this patch, but does accessing ctx->ctxid
outside the IDR lock lead to a use-after-free?

Looking at fastrpc_rpmsg_callback(), idr_find() is called to retrieve the
context, but the spinlock (cctx->lock) is released immediately after without
incrementing the context's reference count.

If another thread drops the final reference to this context concurrently (such
as a timeout or worker thread), fastrpc_context_free() will remove it from the
IDR and free the memory. Can fastrpc_rpmsg_callback() then access freed memory
when checking ctx->ctxid?

[Severity: Critical]
This is a pre-existing issue, but do duplicate Glink completion responses
bypass the sequence validation and cause a use-after-free?

The sequence number check mitigates responses intended for a recycled IDR slot,
but it does not protect against a malicious DSP sending multiple Glink
completion responses for the currently active request.

If a duplicate response is sent, the sequence number matches, and
fastrpc_rpmsg_callback() blindly calls schedule_work(&ctx->put_work) again. If
the first scheduled work has already completed, will the duplicate response
successfully queue it a second time, erroneously dropping the reference count
to zero and freeing the context while the CPU thread is still using it?

> +		dev_dbg(&rpdev->dev,
> +			"Stale glink response ctx 0x%llx (expected seq 0x%llx), dropping\n",
> +			rsp->ctx,
> +			FIELD_GET(FASTRPC_CTXID_SEQ_MASK, ctx->ctxid));
> +		return 0;
> +	}
> +
>  	ctx->retval = rsp->retval;
> +	ctx->is_work_done = true;
>  	complete(&ctx->work);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260713052236.3033744-1-ekansh.gupta@oss.qualcomm.com?part=4