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

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

Patch Review

**Correctness: Good**

The old code was reaching into `ww_mutex` internals:
```c
mutex_lock(&bo->base.resv->lock.base);
...
mutex_unlock(&bo->base.resv->lock.base);
```

This breaks on `PREEMPT_RT` because `ww_mutex.base` becomes an `rt_mutex_base` rather than a `struct mutex`, so `mutex_lock()`/`mutex_unlock()` don't apply.

The fix correctly uses the public ww_mutex API:
```c
ww_mutex_lock(&bo->base.resv->lock, NULL);
...
ww_mutex_unlock(&bo->base.resv->lock);
```

Passing `NULL` as the acquire context to `ww_mutex_lock()` is valid — it means a single lock acquisition without deadlock detection, which matches the original intent of the test (just hold the lock to force the other thread to block).

**Semantic correctness: Good**

Looking at how `dma_resv` is used elsewhere in `dma-resv.h`, the standard wrappers like `dma_resv_lock()` and `dma_resv_unlock()` are thin wrappers around `ww_mutex_lock()`/`ww_mutex_unlock()`. The test intentionally bypasses the `dma_resv_lock()` wrapper (which would call `dma_resv_reset_max_fences()` on unlock) — this is acceptable for a unit test that just needs to hold the raw lock.

**Minor observation:** Ideally the test could use `dma_resv_lock(bo->base.resv, NULL)` and `dma_resv_unlock(bo->base.resv)` instead of going through `resv->lock` directly, which would be even more future-proof against internal struct changes. However, `dma_resv_unlock()` calls `dma_resv_reset_max_fences()` which may have side effects the test doesn't want, so using the `ww_mutex` API directly is a reasonable choice.

**Reviewed-by worthy: Yes.** This is a clean, minimal fix that addresses a real build failure.

---
Generated by Claude Code Patch Reviewer