Claude review: rust: gpu: Add GPU buddy allocator bindings

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

Patch Review

**Doc example type name mismatch (compile error)**

The doc examples import `GpuBuddyAllocFlags` but then use the non-existent type `GpuBuddyFlags`. This would cause doctest compilation failures. It appears in examples 1, 2, and 3:

```rust
// buddy.rs line 19 (example 1 import):
gpu::buddy::{GpuBuddy, GpuBuddyAllocMode, GpuBuddyAllocFlags, GpuBuddyParams},

// buddy.rs line 42 (example 1 usage):
GpuBuddyFlags::default(),
```

This should be `GpuBuddyAllocFlags::default()`. The same issue appears in examples 2 (line 79) and 3 (lines 120, 134, 146).

**Misleading `Range { start: 0, end: 0 }` in first example**

In the first doc example (buddy.rs line 39):
```rust
GpuBuddyAllocMode::Range { start: 0, end: 0 },
```

This sets `GPU_BUDDY_RANGE_ALLOCATION` with `end=0`. In the C code at `buddy.c:626`:
```c
end = end - 1;
```
This causes `end` to underflow to `U64_MAX`, making the range effectively unbounded. The example "works" because the allocator is fresh and happens to allocate at offset 0, but the semantics are wrong — a `Range` with `start: 0, end: 0` doesn't restrict the range at all. The example should either use `GpuBuddyAllocMode::Simple` or specify a proper end value like `end: SZ_1G as u64`.

**Unused C helper: `rust_helper_gpu_buddy_block_size`**

In `rust/helpers/gpu.c` (lines 16-20):
```c
__rust_helper u64 rust_helper_gpu_buddy_block_size(struct gpu_buddy *mm,
                                                   struct gpu_buddy_block *block)
{
    return gpu_buddy_block_size(mm, block);
}
```

This helper is defined but never called from Rust. `AllocatedBlock::size()` (buddy.rs line 608-609) computes the size manually:
```rust
pub fn size(&self) -> usize {
    self.blocks.buddy.params.chunk_size << self.this.order()
}
```

This is functionally equivalent and avoids needing the `gpu_buddy*` pointer, so the approach is fine, but the unused helper should be removed to avoid dead code.

**`AllocatedBlock::size()` returns `usize` — potential overflow on 32-bit**

At buddy.rs line 608:
```rust
pub fn size(&self) -> usize {
    self.blocks.buddy.params.chunk_size << self.this.order()
}
```

If `chunk_size` is 4KB and `order` is large (the max order is 51 per `GPU_BUDDY_MAX_ORDER`), this would overflow `usize` on 32-bit platforms. While GPU drivers are primarily 64-bit, this could be a latent issue. Consider returning `u64` to match the C type (`gpu_buddy_block_size` returns `u64`).

**MAINTAINERS: `rust/helpers/gpu.c` listed under two entries**

The file `rust/helpers/gpu.c` is listed under both "DRM DRIVERS AND INFRASTRUCTURE" and "GPU BUDDY ALLOCATOR" sections. Similarly `rust/kernel/gpu/` appears in both. While dual-listing isn't necessarily wrong (especially if both groups should review changes), it's worth confirming this is intentional rather than accidental.

**Minor: `GpuBuddyInner::drop` takes lock during drop**

At buddy.rs lines 365-373:
```rust
fn drop(self: Pin<&mut Self>) {
    let guard = self.lock();
    unsafe {
        bindings::gpu_buddy_fini(guard.as_raw());
    }
}
```

The lock is taken during `drop()` for `gpu_buddy_fini`. At this point the `Arc` refcount has reached zero, so no other thread can hold a reference. The lock acquisition is technically unnecessary (there can be no contention), but it's not incorrect — it provides a safety margin. Worth a comment noting this is defensive.

**Minor: The `alloc_blocks` initializer field access pattern**

In buddy.rs lines 457-478, the `try_pin_init!` macro body references `buddy` and `list` as field names in the `_:` initializer:
```rust
try_pin_init!(AllocatedBlocks {
    buddy: buddy_arc,
    list <- CListHead::new(),
    _: {
        let guard = buddy.lock();
        ...
        list.as_raw(),
        ...
    }
})
```

This relies on `try_pin_init!` making previously-initialized fields available by name. This is a valid kernel Rust pattern but is quite implicit — a brief comment explaining that `buddy` and `list` refer to the already-initialized fields would help readability.

**Overall**: The architecture is clean and the safety story is well-reasoned. The main blockers are the `GpuBuddyFlags` typo (doctests won't compile) and the misleading `Range { start: 0, end: 0 }` example. The rest are minor cleanups.

---
Generated by Claude Code Patch Reviewer