Claude review: gpu/buddy: Track per-order used blocks with a scoreboard

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

Patch Review

**Correctness: The used scoreboard maintenance is mostly correct, with one item worth double-checking.**

Increment site:
- `mark_allocated()` — block enters allocated state

Decrement sites:
- `mark_free()` — guarded by `gpu_buddy_block_is_allocated(block)`, which is correct because `mark_free` is also called on SPLIT blocks (during the coalescing path in `__gpu_buddy_free` at the bottom: `mark_free(mm, block)`), and those should not decrement the used scoreboard.
- `__gpu_buddy_free()` coalescing loop — guarded by `gpu_buddy_block_is_allocated(block)`, handling the case where an allocated block is consumed during coalescing.

```c
+		if (gpu_buddy_block_is_allocated(block))
+			mm->used_scoreboard[gpu_buddy_block_order(block)]--;
+
		gpu_block_free(mm, block);
```

**Question about the coalescing path in `__gpu_buddy_free()`:** The coalescing loop at line ~277 walks up the tree merging block+buddy pairs. The `block` variable in the loop is the block being freed. On entry to `__gpu_buddy_free`, is `block` ever in the ALLOCATED state? Looking at the callers:
- `mark_free` is called *after* `__gpu_buddy_free` returns (at the bottom of the function)
- `__gpu_buddy_undo_splits` calls it on a FREE block
- `gpu_buddy_free_list_internal` calls `mark_free` then `__gpu_buddy_free` — wait, no, it calls `__gpu_buddy_free` which internally calls `mark_free` at the end.

Actually, looking more carefully at `__gpu_buddy_free`, the block enters as whatever state it is (the callers should have already ensured appropriate state), and the loop checks if `buddy` is free. The `block` at each iteration is the current node walking up the tree. On the first iteration, the block could indeed be allocated (if called from a path that hasn't marked it free yet). But looking at all callers of `__gpu_buddy_free`:

1. `__gpu_buddy_undo_splits` — block is FREE
2. `gpu_buddy_free_list_internal` via `__gpu_buddy_free` — the block state depends on the caller

Actually, re-reading `__gpu_buddy_free` more carefully: it first does a coalescing loop, then calls `mark_free(mm, block)`. The block entering the function may be in ALLOCATED state (from a direct free path). So the guard `if (gpu_buddy_block_is_allocated(block))` in the coalescing loop is correct — it handles the case where an allocated block is being freed and its buddy is also free, so they merge without going through `mark_free` first.

The `gpu_buddy_fini` assertion is a good addition:
```c
for (i = 0; i <= mm->max_order; ++i)
    gpu_buddy_assert(!mm->used_scoreboard[i]);
```

**The print format change** from `free < SZ_1M` to `block_size < SZ_1M` is a sensible improvement — it makes the KiB/MiB display consistent per order rather than per count, so zero-block orders still display in the right unit. This changes output format for all consumers of `drm_buddy_print` / `gpu_buddy_print`, but that's debugfs-only so it should be fine.

**Minor style observation:** The used_scoreboard comment block in `gpu_buddy.h` is quite verbose (6 lines), which is fine for kernel code documenting a non-obvious invariant.

No blocking issues found. The series is well-constructed and the scoreboard bookkeeping appears correct across all state transitions.

---
Generated by Claude Code Patch Reviewer