From mboxrd@z Thu Jan  1 00:00:00 1970
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: misc: fastrpc: Remove buffer from list prior to unmap operation
Date: Sun, 12 Apr 2026 11:44:34 +1000
Message-ID: <review-patch2-20260409062617.1182-3-jianping.li@oss.qualcomm.com>
In-Reply-To: <20260409062617.1182-3-jianping.li@oss.qualcomm.com>
References: <20260409062617.1182-1-jianping.li@oss.qualcomm.com> <20260409062617.1182-3-jianping.li@oss.qualcomm.com>
X-Mailer: Claude Code Patch Reviewer
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0

Patch Review

**Verdict: Reasonable fix with one concern.**

The change moves the `list_del` out of `fastrpc_req_munmap_impl()` and into the caller `fastrpc_req_munmap()`, done under the spinlock before the DSP unmap RPC:

```c
spin_lock(&fl->lock);
list_for_each_entry_safe(iter, b, &fl->mmaps, node) {
    if ((iter->raddr == req.vaddrout) && (iter->size == req.size)) {
        list_del(&iter->node);   // remove before unlocking
        buf = iter;
        break;
    }
}
spin_unlock(&fl->lock);
```

If the DSP unmap fails, the buffer is re-added:

```c
err = fastrpc_req_munmap_impl(fl, buf);
if (err) {
    spin_lock(&fl->lock);
    list_add_tail(&buf->node, &fl->mmaps);
    spin_unlock(&fl->lock);
}
```

This prevents a race where two threads could both find and try to unmap the same buffer. The remove-first, re-add-on-failure pattern is reasonable.

The `fastrpc_req_mmap` error path change is also correct: when `copy_to_user` fails, the buffer (already added to the list) must be removed before calling `fastrpc_req_munmap_impl` (which no longer does `list_del`):

```c
err_copy:
    spin_lock(&fl->lock);
    list_del(&buf->node);
    spin_unlock(&fl->lock);
err_assign:
    fastrpc_req_munmap_impl(fl, buf);
```

**Concern:** After removing the `list_del` from `fastrpc_req_munmap_impl`, ensure all callers handle list removal. There are at least two callers: `fastrpc_req_munmap` (handled) and the `err_assign` path in `fastrpc_req_mmap` (handled via new `err_copy`). The `fastrpc_device_release` path iterates the list and calls `fastrpc_buf_free` directly (not through `_impl`), so it's not affected. This looks complete.

---

---
Generated by Claude Code Patch Reviewer