From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: Introduce dmem driver and implement Xe support Date: Sat, 16 May 2026 12:42:31 +1000 Message-ID: In-Reply-To: <20260512215156.4083082-2-cascardo@igalia.com> References: <20260512215156.4083082-1-cascardo@igalia.com> <20260512215156.4083082-2-cascardo@igalia.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review Good abstraction. The vtable in `igt_dmem_driver.h` is clean and minimal. **Issue: `xe_dmem_allocate_vram` leaks BO on bind failure.** If `__xe_vm_bind_lr_sync` fails, the handle is stored in `xe_ctx->handles[n_bo]` but never closed: ```c err = __xe_bo_create(xe_ctx->fd, 0, len, xe_ctx->vram_region, DRM_XE_GEM_CREATE_FLAG_DEFER_BACKING, NULL, &handle); if (err) goto out; xe_ctx->handles[n_bo] = handle; err = __xe_vm_bind_lr_sync(xe_ctx->fd, xe_ctx->vm, handle, 0, xe_ctx->addr, len, 0); if (err) goto out; /* handle stored but addr not incremented, BO not closed */ ``` When bind fails, the caller sees the error and stops, but `free_vram` walks `handles[0..n_bo-1]` and will try to unbind at an address that was never bound. The stored handle will get a `gem_close` which is fine, but the `xe_vm_unbind_lr_sync` for that address will fail or operate on wrong memory. Consider closing the handle on bind failure, or at minimum zeroing the handle entry. **Issue: `xe_ctx->addr` is monotonically increasing.** After `xe_dmem_free_vram`, `addr` is not reset. This means subsequent `allocate_vram` calls bind at ever-higher VAs. For the existing eviction test (single allocate/free cycle) this is fine, but the new `test_current` in patch 6 does three allocate/free cycles, which will consume `3 * cg_max` worth of VA space. Not fatal, but wasteful and could theoretically exhaust the VA range on very large VRAM systems. **Minor: Error code mismatch in `xe_dmem_init`.** When no VRAM region is found, the function returns `-ENOMEM`, which is misleading. Something like `-ENODEV` would be more appropriate. --- Generated by Claude Code Patch Reviewer