Claude review: drm/buddy: Integrate lockdep annotations for gpu buddy manager

[Claude Code Review Bot <claude-review@example.com>]

Overall Series Review

Subject: drm/buddy: Integrate lockdep annotations for gpu buddy manager
Author: Tejas Upadhyay <tejas.upadhyay@intel.com>
Patches: 4
Reviewed: 2026-05-05T11:39:29.714051

---

This is a single patch adding lockdep annotations to the `gpu_buddy` allocator, closely modeled after the existing `drm_gpusvm_driver_set_lock()` / `drm_gpusvm_driver_lock_held()` pattern. The approach is sound: store a pointer to the driver's `lockdep_map`, then assert it's held on entry to exported APIs. The implementation is mostly correct, but has several gaps and issues:

1. **Incomplete driver coverage**: Only xe is wired up, but amdgpu, i915, and the ttm test mock manager also call gpu_buddy APIs and need `gpu_buddy_driver_set_lock()` calls. Without those, the annotation is inert for 3 of 4 consumers.

2. **Incomplete API coverage**: Two exported functions (`gpu_buddy_fini` and `gpu_buddy_block_print`) plus one drm-layer export (`drm_buddy_block_print`) are missing annotations.

3. **Minor style inconsistency**: The `#else` stubs for the no-LOCKDEP case differ between the macro (uses `do { (void)(mm); (void)(lock); } while (0)`) and the original pattern (uses `do {} while (0)`). Not a bug, but inconsistent with the `drm_gpusvm` template this was copied from.

4. **The macro lacks the local-variable guard present in the drm_gpusvm template**: The `drm_gpusvm_driver_set_lock` macro accesses `(gpusvm)` directly, but the gpu_buddy version uses a local `__mm`. This is actually an *improvement* over the gpusvm original — good.

Overall this is a reasonable v1 that needs a respin to cover the remaining callers and APIs.

---
Generated by Claude Code Patch Reviewer