From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/panthor: Don't use the racy drm_gem_lru_remove() helper Date: Thu, 07 May 2026 13:31:56 +1000 Message-ID: In-Reply-To: <20260506-panthor-shrinker-fixes-v1-1-e7721526de96@collabora.com> References: <20260506-panthor-shrinker-fixes-v1-0-e7721526de96@collabora.com> <20260506-panthor-shrinker-fixes-v1-1-e7721526de96@collabora.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review **Approach:** Instead of calling `drm_gem_lru_remove()` when a BO becomes u= nreclaimable (which is racy), add a new `unreclaimable` LRU list and move B= Os 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 =E2=80=94 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 cr= eation. Without this, a BO created but never explicitly placed in an LRU wo= uld have `obj->lru =3D=3D NULL`, and `drm_gem_object_release()` (after patc= h 3) would skip removal =E2=80=94 that's fine, but having them tracked in a= list is cleaner and consistent. The init ordering in `panthor_gem_shrinker_init()` is correct =E2=80=94 the= `unreclaimable` LRU is initialized before the others, and all share the sa= me `ptdev->reclaim.lock` mutex. No issues found. Patch looks correct. --- Generated by Claude Code Patch Reviewer