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: Fix a race in the shrinker logic Date: Thu, 07 May 2026 13:31:55 +1000 Message-ID: In-Reply-To: <20260506-panthor-shrinker-fixes-v1-0-e7721526de96@collabora.com> References: <20260506-panthor-shrinker-fixes-v1-0-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 Overall Series Review Subject: drm/panthor: Fix a race in the shrinker logic Author: Boris Brezillon Patches: 9 Reviewed: 2026-05-07T13:31:55.806526 --- This is a well-analyzed and cleanly structured 3-patch series from Boris Br= ezillon fixing a real race condition between `drm_gem_lru_remove()` and `dr= m_gem_lru_scan()` in the DRM GEM LRU/shrinker infrastructure. The core prob= lem: `drm_gem_lru_remove()` reads `obj->lru` without the LRU lock, but `drm= _gem_lru_scan()` temporarily moves objects to a stack-allocated `still_in_l= ru` LRU =E2=80=94 if the timing is wrong, `drm_gem_lru_remove()` dereferenc= es a stale pointer to a stack object that no longer exists (UAF). The series is logically ordered: (1) fix the panthor driver to stop using t= he racy API, (2) fix a second race in the core `drm_gem_lru_scan()`, (3) re= move the racy `drm_gem_lru_remove()` entirely. All three patches have Revie= wed-by from the reporter (Chia-I Wu). The approach is sound =E2=80=94 rathe= r than trying to make `drm_gem_lru_remove()` safe (which would require exte= rnal locking that defeats its purpose), the series eliminates the problemat= ic API. The series looks good to me and ready to merge. One minor concern noted bel= ow in Patch 2. --- Generated by Claude Code Patch Reviewer