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

[Claude Code Review Bot <claude-review@example.com>]

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