[PATCH] misc: fastrpc: take fl->lock when moving mmaps on interrupted invoke

[PATCH] misc: fastrpc: take fl->lock when moving mmaps on interrupted invoke

[Junrui Luo]

When an invoke is interrupted by a signal,
wait_for_completion_interruptible() returns -ERESTARTSYS and
fastrpc_internal_invoke() moves every buffer from fl->mmaps onto
cctx->invoke_interrupted_mmaps. This list_del()/list_add_tail() walk
runs without holding fl->lock, the lock that serialises fl->mmaps in
fastrpc_req_mmap() and fastrpc_req_munmap() everywhere else.

Take fl->lock around the move, matching every other fl->mmaps accessor.

Fixes: 76e8e4ace1ed ("misc: fastrpc: Safekeep mmaps on interrupted invoke")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
---
 drivers/misc/fastrpc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 1080f9acf70a..1601c9667d0b 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -1259,10 +1259,12 @@ static int fastrpc_internal_invoke(struct fastrpc_user *fl,  u32 kernel,
 	}
 
 	if (err == -ERESTARTSYS) {
+		spin_lock(&fl->lock);
 		list_for_each_entry_safe(buf, b, &fl->mmaps, node) {
 			list_del(&buf->node);
 			list_add_tail(&buf->node, &fl->cctx->invoke_interrupted_mmaps);
 		}
+		spin_unlock(&fl->lock);
 	}
 
 	if (err)

---
base-commit: e43ffb69e0438cddd72aaa30898b4dc446f664f8
change-id: 20260602-fixes-ba3a01f66f34

Best regards,
-- 
Junrui Luo <moonafterrain@outlook.com>

Claude review: misc: fastrpc: take fl->lock when moving mmaps on interrupted invoke

[Claude Code Review Bot]

Overall Series Review

Subject: misc: fastrpc: take fl->lock when moving mmaps on interrupted invoke
Author: Junrui Luo <moonafterrain@outlook.com>
Patches: 1
Reviewed: 2026-06-04T13:14:39.432840

---

This is a single-patch fix for a missing lock in the FastRPC driver's signal-interrupted invoke path. The commit message correctly identifies the bug: `fl->mmaps` is manipulated without `fl->lock` when moving entries to `cctx->invoke_interrupted_mmaps` after `-ERESTARTSYS`. The fix is correct for the `fl->mmaps` side, but there is a remaining concern about the destination list.

**Verdict: The patch is a net improvement and fixes a real race, but has an incomplete locking story for the destination list.**

---

---
Generated by Claude Code Patch Reviewer

Claude review: misc: fastrpc: take fl->lock when moving mmaps on interrupted invoke

[Claude Code Review Bot]

Patch Review

**What it does:** Adds `spin_lock(&fl->lock)` / `spin_unlock(&fl->lock)` around the `list_for_each_entry_safe` loop in the `-ERESTARTSYS` path of `fastrpc_internal_invoke()`.

**Positive:**
- The bug is real. Every other accessor of `fl->mmaps` holds `fl->lock` — `fastrpc_req_mmap()` at line 1988, `fastrpc_req_munmap()` at line 1888, `fastrpc_req_munmap_impl()` at line 1868. The unprotected `list_del()` in the interrupt path could race with any of these.
- The commit message is clear and correctly identifies the Fixes: tag for the commit that introduced the bug.
- The `Cc: stable` tag is appropriate.

**Concern — destination list `cctx->invoke_interrupted_mmaps` is also unprotected:**

The patch protects the *source* list (`fl->mmaps`) with `fl->lock`, but the *destination* list (`fl->cctx->invoke_interrupted_mmaps`) belongs to the shared `fastrpc_channel_ctx`, not to this `fl`. Multiple `fastrpc_user` instances can share the same `cctx`. If two users are interrupted concurrently, each holds their own `fl->lock`, and both do:

```c
list_add_tail(&buf->node, &fl->cctx->invoke_interrupted_mmaps);
```

This is a concurrent modification of the same list without a common lock — `fl->lock` is per-user, so it provides no mutual exclusion between different users on the same channel. The `cctx` has its own `spinlock_t lock` (line 273) that could be used here, but this patch does not acquire it.

The only other accessor of `invoke_interrupted_mmaps` is in `fastrpc_rpmsg_remove()` (line 2495), which runs during channel teardown and iterates the list without any lock:

```c
list_for_each_entry_safe(buf, b, &cctx->invoke_interrupted_mmaps, node)
    list_del(&buf->node);
```

That teardown path also has a potential race with ongoing invokes, though it's likely mitigated by the device going away.

**Recommendation:** This patch should either also acquire `cctx->lock` around the `list_add_tail` to protect the destination list, or the commit message should note that `invoke_interrupted_mmaps` is a known pre-existing issue being addressed separately. As-is, the patch fixes one race but leaves a second race on the same code path. A nested locking approach (hold `fl->lock` for the `list_del`, then acquire `cctx->lock` for the `list_add_tail`) would work, or both operations could be done under `cctx->lock` if the lock ordering allows it.

**Minor nit (not blocking):** The `fastrpc_rpmsg_remove()` cleanup at line 2495-2496 does `list_del(&buf->node)` but never frees `buf`, which looks like a memory leak. This is pre-existing and not introduced by this patch, but worth noting.

---
Generated by Claude Code Patch Reviewer