Claude review: drm/panthor: Add a GEM shrinker

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

Overall Series Review

Subject: drm/panthor: Add a GEM shrinker
Author: Boris Brezillon <boris.brezillon@collabora.com>
Patches: 11
Reviewed: 2026-03-10T12:15:40.499562

---

This is a well-structured 9-patch series that adds GEM buffer reclaim (shrinker) support to the panthor GPU driver. The series follows a logical progression: first a small DRM core fix, then preparatory refactoring (moving code, splitting helpers), a major transition away from `drm_gem_shmem_object` to a custom GEM implementation, lazy page allocation on mmap, mmap tracking, and finally the shrinker itself. The approach is sensible — using `_trylock()` throughout the reclaim path to avoid lock ordering issues is pragmatic, even if it means missing some reclaim opportunities under contention.

The series is at v5 and most patches have R-b tags from Steven Price and Liviu Dudau. The overall design is sound but I have several concerns, primarily around locking subtleties in the shrinker and eviction paths.

**Key concerns:**
1. The `panthor_vm_evict_bo_mappings_locked()` function does lock-then-break with incomplete rollback — if a `panthor_vm_lock_region()` fails mid-way through VMAs, some VMAs are evicted and some are not, leaving the BO in a partially-evicted state.
2. The `panthor_mmu_reclaim_priv_bos()` uses `vm->reclaim.lru_node.prev == &vms` as a check — this is fragile and relies on list implementation details.
3. In patch 8 (mmap tracking), the `refcount_t` usage pattern with `refcount_set(..., 1)` inside a double-check lock is unusual and deserves scrutiny.
4. The `gpu_mapped_count` is modified without holding the `reclaim.lock`, creating a potential race in `panthor_gem_shrinker_count()`.

---
Generated by Claude Code Patch Reviewer