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/nouveau: fix nvkm_device leak on aperture removal failure Date: Sun, 12 Apr 2026 09:12:26 +1000 Message-ID: In-Reply-To: <20260411062938.22925-1-devnexen@gmail.com> References: <20260411062938.22925-1-devnexen@gmail.com> <20260411062938.22925-1-devnexen@gmail.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 **Correctness: Confirmed.** The probe function allocates the nvkm device early: ```c ret =3D nvkm_device_pci_new(pdev, nouveau_config, nouveau_debug, &device); if (ret) return ret; ``` `nvkm_device_pci_new()` internally calls `pci_enable_device()` (at `nvkm/en= gine/device/pci.c:1662`), so on success we hold both the device allocation = and a PCI enable reference. The very next fallible call is: ```c ret =3D aperture_remove_conflicting_pci_devices(pdev, driver_pci.name); if (ret) - return ret; + goto fail_nvkm; ``` The old `return ret` skips cleanup entirely. The `fail_nvkm` label correctl= y runs: ```c fail_nvkm: nvkm_device_del(&device); return ret; ``` And `nvkm_device_del` invokes `nvkm_device_pci_dtor()` which calls `pci_dis= able_device()` (`pci.c:1635`), properly balancing the enable taken during `= nvkm_device_pci_new()`. There is no double-free risk here: at this point in the probe sequence, no = other resources (the second `pci_enable_device` at line 891, `nouveau_drm_d= evice_new`, etc.) have been allocated yet, so jumping to `fail_nvkm` =E2=80= =94 which only tears down the nvkm device =E2=80=94 is the correct label. **Commit message:** Accurate. The description correctly identifies what lea= ks, why, and which commit introduced the problem. **Tags:** `Fixes:` and `Cc: stable` are appropriate. **No issues found.** This could take a: Reviewed-by if you agree with the analysis. --- Generated by Claude Code Patch Reviewer