Claude review: gpu/buddy: Fix use-after-free in split_block() call sites

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

Patch Review

**Correctness: Good fix, addresses a real bug.**

The existing code at all four `err_undo` paths calls `__gpu_buddy_free(mm, block, false)` without first removing `block` from the rbtree. Since a failed `split_block()` returns before `mark_split()`, the block is still FREE and linked in the tree. `__gpu_buddy_free()` will then try to coalesce with the buddy, calling `gpu_block_free(mm, block)` which frees the block's memory while its `rb` node is still linked. This is confirmed by examining the existing code at `buddy.c:737-741` where the rbtree_remove was missing.

The fix correctly adds `rbtree_remove(mm, block)` before each `__gpu_buddy_free()` call, matching the pattern already used in `__force_merge()` at line 337.

**One observation on the `alloc_from_freetree` error path:**

```c
err_undo:
	if (tmp != order) {
		rbtree_remove(mm, block);
		__gpu_buddy_free(mm, block, false);
	}
```

The `if (tmp != order)` guard: after a failed `split_block()`, `block` points to the block that failed to split, which is still at order `tmp`. Since we entered the `while (tmp != order)` loop, `tmp > order` at that point. However, if `split_block()` succeeds but something updates `block` to point to a child (at `block = block->right; tmp--;`), by the time a *subsequent* iteration of the loop fails, `block` points to the right child which is at order `tmp-1` (the decremented value). So `tmp != order` is indeed always true here, as patch 2 correctly observes.

No issues. This should probably carry a `Cc: stable@vger.kernel.org` tag and a `Fixes:` tag.

---
Generated by Claude Code Patch Reviewer