Claude review: drm/panthor: Don't use the racy drm_gem_lru_remove() helper

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

Patch Review

**Approach:** Instead of calling `drm_gem_lru_remove()` when a BO becomes unreclaimable (which is racy), add a new `unreclaimable` LRU list and move BOs there instead. All BOs start in this list at creation time.

This is the right fix for the panthor side. The key change in `panthor_gem_update_reclaim_state_locked()`:

```c
case PANTHOR_GEM_UNRECLAIMABLE:
-	drm_gem_lru_remove(&bo->base);
+	drm_gem_lru_move_tail(&ptdev->reclaim.unreclaimable, &bo->base);
```

`drm_gem_lru_move_tail()` acquires the lock internally and is safe because it doesn't read `obj->lru` before acquiring the lock — it takes the target LRU's lock directly.

The addition in `panthor_gem_create()` is correct:

```c
+	drm_gem_lru_move_tail(&ptdev->reclaim.unreclaimable, &bo->base);
	return bo;
```

This ensures every BO is in a real (heap-allocated, long-lived) LRU from creation. Without this, a BO created but never explicitly placed in an LRU would have `obj->lru == NULL`, and `drm_gem_object_release()` (after patch 3) would skip removal — that's fine, but having them tracked in a list is cleaner and consistent.

The init ordering in `panthor_gem_shrinker_init()` is correct — the `unreclaimable` LRU is initialized before the others, and all share the same `ptdev->reclaim.lock` mutex.

No issues found. Patch looks correct.

---
Generated by Claude Code Patch Reviewer