Claude review: gpu/buddy: Introduce __gpu_buddy_undo_splits() helper

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

Patch Review

**Correctness: Correct refactor, but one subtle behavioral change in `alloc_from_freetree`.**

The helper extracts the repeated pattern:

```c
static void __gpu_buddy_undo_splits(struct gpu_buddy *mm,
				    struct gpu_buddy_block *block)
{
	struct gpu_buddy_block *buddy = __get_buddy(block);

	if (buddy &&
	    (gpu_buddy_block_is_free(block) &&
	     gpu_buddy_block_is_free(buddy))) {
		rbtree_remove(mm, block);
		__gpu_buddy_free(mm, block, false);
	}
}
```

For the three sites in `__alloc_range_bias`, `gpu_buddy_offset_aligned_allocation`, and `__alloc_range`, this is a direct extraction — those all had the `if (buddy && ...)` guard already.

**However**, in `alloc_from_freetree` (after patch 2's cleanup), the error path was:
```c
err_undo:
	rbtree_remove(mm, block);
	__gpu_buddy_free(mm, block, false);
```
— i.e., **unconditional** `rbtree_remove` + `__gpu_buddy_free`. Now it becomes:
```c
err_undo:
	__gpu_buddy_undo_splits(mm, block);
```
which adds a **new guard** (`if buddy && both-free`). This is actually a tightening — if the buddy is not free or doesn't exist, the function now does nothing instead of unconditionally freeing.

**Is this correct?** When `split_block()` fails in `alloc_from_freetree`, the block is still FREE (split didn't complete). After the first successful split, the left child is marked free and the right child becomes `block` (via `block = block->right`). The right child is also marked free by `split_block()`. So after a failed split:
- `block` is FREE (the split that failed didn't change its state)
- `buddy` (left sibling) is FREE (created by the *previous* successful split)

So the guard `buddy && both-free` should be true in the normal case. But what about the *first* iteration failure? Then `block` is the original block from the tree — it has no buddy from splitting (the `__get_buddy` might return a pre-existing buddy). This seems safe: if there's no buddy or the buddy isn't free, we just skip the undo, and `__gpu_buddy_free` would handle the block via the `mark_free` path at the bottom anyway.

This is acceptable but the commit message could mention that `alloc_from_freetree` gains the buddy guard it previously lacked.

---
Generated by Claude Code Patch Reviewer