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/gem: Make the GEM LRU lock part of drm_device Date: Sat, 16 May 2026 14:06:15 +1000 Message-ID: In-Reply-To: <20260512-panthor-shrinker-fixes-v3-1-3bf066259471@collabora.com> References: <20260512-panthor-shrinker-fixes-v3-1-3bf066259471@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/gem: Make the GEM LRU lock part of drm_device Author: Boris Brezillon Patches: 5 Reviewed: 2026-05-16T14:06:15.229271 --- This is a single patch (v3, distilled from an earlier 4-patch series) that = addresses a real race condition in the DRM GEM LRU shrinker infrastructure.= The race is between `drm_gem_lru_remove()` and `drm_gem_lru_scan()`: the o= ld code reads `obj->lru` without the lock, dereferences it to get `lru->loc= k`, then takes that lock =E2=80=94 but `obj->lru` can change (or become NUL= L) between the read and the lock acquisition. Since `drm_gem_lru_scan()` us= es a stack-allocated `still_in_lru`, this can result in a use-after-free. The fix is clean and well-motivated: move the lock from `struct drm_gem_lru= ` to `struct drm_device`, eliminating the chicken-and-egg problem entirely.= The commit message clearly explains the rationale and acknowledges the tra= de-off (coarser locking, with a path to finer-grained locking if ever neede= d). The patch already has Reviewed-by tags from Rob Clark (MSM maintainer) = and Liviu Dudau. **Verdict: This patch looks correct and is ready to merge.** I have only mi= nor observations below. --- Generated by Claude Code Patch Reviewer