From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/gem: Stop exposing the racy/unsafe drm_gem_lru_remove() helper
Date: Thu, 07 May 2026 13:31:56 +1000 [thread overview]
Message-ID: <review-patch3-20260506-panthor-shrinker-fixes-v1-3-e7721526de96@collabora.com> (raw)
In-Reply-To: <20260506-panthor-shrinker-fixes-v1-3-e7721526de96@collabora.com>
Patch Review
This patch removes the public `drm_gem_lru_remove()` function entirely and inlines a safe version in `drm_gem_object_release()`. The key insight: at `drm_gem_object_release()` time, refcount is zero, meaning no other code path can concurrently change `obj->lru`, so it's safe to read `obj->lru` without the LRU lock, then acquire the lock to remove.
```c
+ if (obj->lru) {
+ guard(mutex)(obj->lru->lock);
+ drm_gem_lru_remove_locked(obj);
+ }
```
The `guard(mutex)` usage is appropriate — the scope-based locking will release the mutex at the end of the enclosing block (the `if` block).
The `drm_gem_lru_remove_locked()` static function is moved from its original location (near the other LRU helpers) up to just before `drm_gem_object_release()` so it's available at the call site. This is a code motion, not a change.
The removal of the declaration from `drm_gem.h`:
```c
-void drm_gem_lru_remove(struct drm_gem_object *obj);
```
This is correct. After patch 1 removes the only panthor call site, and this patch removes the function definition and the call in `drm_gem_object_release()`, there are no remaining callers. The cover letter notes MSM is the only other user of `drm_gem_lru`, but MSM doesn't use `drm_gem_lru_remove()` — it uses `drm_gem_lru_move_tail()` to move objects between LRUs, which is the safe pattern.
**One observation about EXPORT_SYMBOL:** The patch removes the `EXPORT_SYMBOL(drm_gem_lru_remove)` line along with the function. This is correct — no out-of-tree users should depend on this racy API.
No issues found. Patch is correct and a good cleanup.
**Summary:** All three patches are well-reasoned, correctly fix real races, and the series ordering is logical. The Reviewed-by tags from the reporter are present. This series looks good to merge. The only thing I'd flag is ensuring MSM is tested or at least audited that it doesn't call `drm_gem_lru_remove()` anywhere — which the cover letter already addresses by CC'ing MSM maintainers.
---
Generated by Claude Code Patch Reviewer
next prev parent reply other threads:[~2026-05-07 3:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-06 12:16 [PATCH 0/3] drm/panthor: Fix a race in the shrinker logic Boris Brezillon
2026-05-06 12:16 ` [PATCH 1/3] drm/panthor: Don't use the racy drm_gem_lru_remove() helper Boris Brezillon
2026-05-06 15:40 ` Steven Price
2026-05-06 16:25 ` Boris Brezillon
2026-05-07 3:31 ` Claude review: " Claude Code Review Bot
2026-05-06 12:16 ` [PATCH 2/3] drm/gem: Fix a race between drm_gem_lru_scan() and drm_gem_object_release() Boris Brezillon
2026-05-06 13:21 ` Rob Clark
2026-05-06 14:33 ` Boris Brezillon
2026-05-07 3:31 ` Claude review: " Claude Code Review Bot
2026-05-06 12:16 ` [PATCH 3/3] drm/gem: Stop exposing the racy/unsafe drm_gem_lru_remove() helper Boris Brezillon
2026-05-06 15:40 ` Steven Price
2026-05-07 3:31 ` Claude Code Review Bot [this message]
2026-05-07 3:31 ` Claude review: drm/panthor: Fix a race in the shrinker logic Claude Code Review Bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=review-patch3-20260506-panthor-shrinker-fixes-v1-3-e7721526de96@collabora.com \
--to=claude-review@example.com \
--cc=dri-devel-reviews@example.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox