[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

[PATCH v2] 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>
---
Changes since v1:
- Use the correct locking primitive (Jouni)

 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..f3103307b5df9 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);
+	dma_resv_lock(bo->base.resv, NULL);
 
 	wake_up_process(task);
 	msleep(20);
 	err = kthread_stop(task);
 
-	mutex_unlock(&bo->base.resv->lock.base);
+	dma_resv_unlock(bo->base.resv);
 
 	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: 3
Reviewed: 2026-03-05T13:40:45.267716

---

This is a single-patch fix for a compile error in TTM kunit tests when `CONFIG_PREEMPT_RT` is enabled. On PREEMPT_RT, `struct mutex` is replaced by `struct rt_mutex`, so directly accessing `bo->base.resv->lock.base` as a `mutex` fails to compile. The fix correctly switches to the proper `dma_resv_lock()`/`dma_resv_unlock()` API instead of reaching into ww_mutex internals. This is a clean, straightforward fix.

**Verdict: 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

**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