Claude review: drm/ttm: Fix bo resource use-after-free

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

Patch Review

**Bug Analysis:** The bug was introduced by commit `c06da4b3573a` which cached `bo->resource` into a local variable `res` at the top of `ttm_bo_swapout_cb()`. The problem is that `ttm_bo_handle_move_mem()` at line 1160 calls into the driver's `move` callback (line 157 of the same file), which replaces `bo->resource` with the new `evict_mem` and frees the old resource. After this call returns, the local `res` variable points to freed memory.

The stale `res` pointer was then used:
1. At the `ttm_resource_del_bulk_move(res, bo)` call
2. At the `ttm_resource_add_bulk_move(res, bo)` call  
3. At the `ttm_resource_move_to_lru_tail(res)` call — which is where the NULL deref in the stack trace occurs

**Fix correctness:** The fix simply removes the local `res` variable and replaces all uses with `bo->resource`, which always points to the current (valid) resource. This is correct because:
- After `ttm_bo_handle_move_mem()` completes successfully, `bo->resource` points to the newly allocated system memory resource
- The bulk_move and lru_tail operations should operate on the current resource, not the old (freed) one

**Minor observations:**

- The `place` initialization `{ .mem_type = bo->resource->mem_type }` at line 1110 is fine — `bo->resource` is valid at function entry and `place` captures the value (not the pointer).
- The fix is appropriately tagged with `Fixes:` and Cc's the relevant maintainers.
- No concerns about the locking — the `spin_lock(&bdev->lru_lock)` sections after the move are operating on the correct (new) resource.

**No issues found.** Clean, minimal, correct fix for a real UAF.

---
Generated by Claude Code Patch Reviewer