Claude review: drm/ttm: Split cgroup charge and resource allocation

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

Patch Review

**Purpose:** Decouples cgroup charging from resource allocation so the charge persists across allocation retries. This prevents a TOCTOU race where protection status is checked without the allocation being charged.

**Design:** This is a key enabler for patch 5. The new `ttm_resource_try_charge()` charges the cgroup first, then `ttm_resource_alloc()` takes the charged pool directly. The charge ownership is transferred to the TTM resource on success, with explicit cleanup on failure paths.

The ownership transfer is well-documented:
```c
	/*
	 * Ownership of charge_pool has been transferred to the TTM resource,
	 * don't make the caller think we still hold a reference to it.
	 */
	alloc_state->charge_pool = NULL;
```

**Eviction callback charge attempt:** In `ttm_bo_evict_cb`, after successful eviction:
```c
	if (!evict_walk->alloc_state->charge_pool) {
		lret = ttm_resource_try_charge(bo, evict_walk->place,
					       &evict_walk->alloc_state->charge_pool, NULL);
		if (lret == -EAGAIN)
			return -EBUSY;
		else if (lret)
			return lret;
	}
```
The `-EAGAIN` → `-EBUSY` mapping here will propagate up through `ttm_lru_walk_for_evict`. Since `lret` will be negative, the `!lret` checks in the retry loops won't trigger, effectively stopping the eviction walk. This seems correct — if the cgroup limit prevents charging even after eviction, there's no point continuing.

`NULL` is passed for `ret_limit_pool` in the eviction callback's charge attempt, which is fine since the limit pool was already established during the initial `ttm_bo_alloc_at_place` call.

The uncharge paths in `ttm_bo_alloc_resource` look correct — `dmem_cgroup_uncharge()` is called before `dmem_cgroup_pool_state_put()` on each failure path, and the `-EBUSY` continue path also uncharges.

---
Generated by Claude Code Patch Reviewer