[PATCH] drm/ttm/tests: Fix build failure on PREEMPT_RT

[PATCH] drm/ttm/tests: Fix build failure on PREEMPT_RT

[Maarten Lankhorst]

Fix a compile error in the kunit tests when CONFIG_PREEMPT_RT is
enabled, and the normal mutex is converted into a rtmutex.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202602261547.3bM6yVAS-lkp@intel.com/
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
---
 drivers/gpu/drm/ttm/tests/ttm_bo_test.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/tests/ttm_bo_test.c b/drivers/gpu/drm/ttm/tests/ttm_bo_test.c
index d468f83220720..2ba5ddf2b1c9e 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_bo_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_bo_test.c
@@ -222,13 +222,13 @@ static void ttm_bo_reserve_interrupted(struct kunit *test)
 		KUNIT_FAIL(test, "Couldn't create ttm bo reserve task\n");
 
 	/* Take a lock so the threaded reserve has to wait */
-	mutex_lock(&bo->base.resv->lock.base);
+	ww_mutex_lock(&bo->base.resv->lock, NULL);
 
 	wake_up_process(task);
 	msleep(20);
 	err = kthread_stop(task);
 
-	mutex_unlock(&bo->base.resv->lock.base);
+	ww_mutex_unlock(&bo->base.resv->lock);
 
 	KUNIT_ASSERT_EQ(test, err, -ERESTARTSYS);
 }
-- 
2.51.0

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

[Claude Code Review Bot]

Overall Series Review

Subject: drm/ttm/tests: Fix build failure on PREEMPT_RT
Author: Maarten Lankhorst <dev@lankhorst.se>
Patches: 1
Reviewed: 2026-02-27T11:52:16.138579

---

This is a single-patch fix for a build failure in the TTM kunit tests when `CONFIG_PREEMPT_RT` is enabled. The fix is straightforward and correct: it replaces direct access to the internal `mutex` base member of a `ww_mutex` with the proper `ww_mutex_lock()`/`ww_mutex_unlock()` API calls. On PREEMPT_RT kernels, the underlying mutex implementation changes from a standard `mutex` to an `rt_mutex`, so accessing `.lock.base` directly breaks.

The patch is well-motivated (reported by the kernel test robot), small, and low-risk.

**Recommendation: Looks good.**

---
Generated by Claude Code Patch Reviewer

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

[Claude Code Review Bot]

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