Claude review: drm/ttm/tests: Fix build failure on PREEMPT_RT

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

Patch Review

**Problem:** The test `ttm_bo_reserve_interrupted` directly locks the underlying mutex of the dma_resv's ww_mutex via `mutex_lock(&bo->base.resv->lock.base)`. On PREEMPT_RT, `struct mutex` becomes `struct rt_mutex` with a different layout, causing a compile error.

**Fix analysis:**

The change from:
```c
mutex_lock(&bo->base.resv->lock.base);
...
mutex_unlock(&bo->base.resv->lock.base);
```
to:
```c
dma_resv_lock(bo->base.resv, NULL);
...
dma_resv_unlock(bo->base.resv);
```

is correct. Looking at the implementation in `include/linux/dma-resv.h:342`, `dma_resv_lock()` with a NULL context calls `ww_mutex_lock(&obj->lock, NULL)`, which behaves as a plain lock without deadlock avoidance — semantically equivalent to what the old code was doing by locking the base mutex directly.

**Semantic correctness:** The test's purpose is for the main thread to hold the reservation lock, then have `threaded_ttm_bo_reserve` (line 184) attempt to acquire it via `ttm_bo_reserve()` with a proper `ww_acquire_ctx`, expecting the thread to be interrupted and return `-ERESTARTSYS`. Using `dma_resv_lock(NULL)` vs raw `mutex_lock` on the base doesn't change the contention behavior — the threaded locker will still block and get signaled.

**Minor note:** `dma_resv_unlock()` (line 461) calls `dma_resv_reset_max_fences(obj)` before `ww_mutex_unlock()`, which zeroes `obj->max_fences`. This is a harmless side effect in this test context since no fences are attached.

**v1 → v2 change:** The changelog says "Use the correct locking primitive (Jouni)", which aligns with this being the v2 improvement — using the proper API rather than some other workaround (likely `#ifdef PREEMPT_RT` or similar in v1).

**Reviewed-by worthy.** No issues found.

---
Generated by Claude Code Patch Reviewer