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/amdgpu: fix lock leak on ENOMEM in AMDGPU_GEM_OP_GET_MAPPING_INFO Date: Mon, 18 May 2026 16:08:13 +1000 Message-ID: In-Reply-To: <20260517131742.3435209-1-michael.bommarito@gmail.com> References: <20260517131742.3435209-1-michael.bommarito@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/amdgpu: fix lock leak on ENOMEM in AMDGPU_GEM_OP_GET_MAPPING_I= NFO Author: Michael Bommarito Patches: 1 Reviewed: 2026-05-18T16:08:13.978576 --- This is a single-patch series fixing a genuine resource leak bug in `amdgpu= _gem_op_ioctl()`. The analysis is correct: when `kvcalloc()` fails at line = 1093, the original code returned `-ENOMEM` directly, bypassing the `out_exe= c` cleanup label. This leaked the `drm_exec` lock context (which holds the = GEM object's `dma_resv` and the VM root PD's `dma_resv`) and the `drm_gem_o= bject` reference. The fix is mechanical and obviously correct =E2=80=94 it sets `r =3D -ENOME= M` and jumps to `out_exec`, which calls `drm_exec_fini(&exec)` and `drm_gem= _object_put(gobj)`, matching the cleanup pattern used by every other error = path in this function. The commit message is thorough and well-written. It identifies the specific= resources leaked, explains the user-visible impact (unprivileged local DoS= via stuck D-state task), references the related work by Ziyi Guo on `num_e= ntries` validation, and correctly notes the fix was not runtime-tested on p= atched kernel. The `Fixes:` and `Cc: stable` tags are appropriate. **Verdict: This patch looks correct and ready to apply.** --- --- Generated by Claude Code Patch Reviewer