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/shmem-helper: Fix huge page mapping in fault handler Date: Sun, 22 Mar 2026 04:58:23 +1000 Message-ID: In-Reply-To: <20260319015224.46896-1-pedrodemargomes@gmail.com> References: <20260319015224.46896-1-pedrodemargomes@gmail.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/shmem-helper: Fix huge page mapping in fault handler Author: Pedro Demarchi Gomes Patches: 2 Reviewed: 2026-03-22T04:58:23.495148 --- This is a single-patch fix for a real race condition in `drm_gem_shmem_help= er.c` where two concurrent page faults within the same PMD range can confli= ct =E2=80=94 one installing a PMD mapping via `vmf_insert_pfn_pmd()` while = the other attempts a PTE mapping via `vmf_insert_pfn()`, triggering a BUG i= n `walk_to_pmd()`. The fundamental approach is correct: adding a `.huge_fault` callback separa= tes PMD-level faults from PTE-level faults, letting the MM core route them = through the proper path (`create_huge_pmd()` at mm/memory.c:6417 only calls= `.huge_fault` when `pmd_none()` is true). However, this patch is based on = an older tree and **does not apply to drm-next**, which has already refacto= red this code significantly (adding `drm_gem_shmem_try_insert_pfn_pmd`, `fo= lio_mark_accessed`, `pfn_mkwrite` callback, etc.). The patch needs to be re= based. --- Generated by Claude Code Patch Reviewer