[PATCH 0/2] rust: kunit: add optional assertions to catch taint and lockdep warnings

[Malte Wechter]

Add configs that enable extra assertions to be emitted to KUnit test
cases. This makes a subset of concurrency related warnings fail unit test
cases, and not stay as silent warnings.

Signed-off-by: Malte Wechter <maltew...@gmail.com>
---
Malte Wechter (2):
rust: kunit: add config to fail kunit tests if a lockdep warning is triggered
rust: kunit: add config to fail kunit if TAINT_WARN is set

lib/kunit/Kconfig | 24 ++++++++++++++++++++++++
rust/macros/kunit.rs | 21 +++++++++++++++++++++
2 files changed, 45 insertions(+)
---
base-commit: 8cdeaa50eae8dad34885515f62559ee83e7e8dda
change-id: 20260812-lockdep-kunit-9628f4bcad90

Best regards,
--
Malte Wechter <maltew...@gmail.com>

[Malte Wechter]

When running KUnit tests and a lockdep warning is triggered, the test is
still marked as passed based only on if test assertions are true.
Thus, add a Kconfig option CONFIG_RUST_LOCKDEP_KUNIT_DEBUG_LOCKS. When
this option selected, if lockdep triggers during a test, fail the test.

Signed-off-by: Malte Wechter <maltew...@gmail.com>
---

lib/kunit/Kconfig | 13 +++++++++++++
rust/macros/kunit.rs | 10 ++++++++++
2 files changed, 23 insertions(+)

diff --git a/lib/kunit/Kconfig b/lib/kunit/Kconfig
index 94ff8e4089bfb..30bac00c42ce1 100644
--- a/lib/kunit/Kconfig
+++ b/lib/kunit/Kconfig
@@ -142,4 +142,17 @@ config KUNIT_UML_PCI

If unsure, say N.

+config RUST_LOCKDEP_KUNIT_DEBUG_LOCKS
+ bool "Enable extra debug_locks assertion in Rust KUnit tests"
+ depends on RUST
+ depends on LOCKDEP
+ default n
+ help
+ Adds an extra assertion to each Rust kunit test case that asserts
+ that the debug_locks flag from `lockdep` is unchanged. This is useful
+ when writing unit tests that could potentially trigger a lockdep warning,
+ this makes it so the KUnit test does not succeed if the test assertions are
+ true, but a lockdep warning is triggered.
+
+ If unsure, say N.
endif # KUNIT
diff --git a/rust/macros/kunit.rs b/rust/macros/kunit.rs
index ae20ed6768f15..d1cd0349f86f0 100644
--- a/rust/macros/kunit.rs
+++ b/rust/macros/kunit.rs
@@ -144,9 +144,19 @@ macro_rules! assert_eq {
// here to reduce the length of the assert message.
#(#cfg_attrs)*
{
+ #[cfg(CONFIG_RUST_LOCKDEP_KUNIT_DEBUG_LOCKS)]
+ let __debug_locks_snapshot = ::kernel::bindings::debug_locks;
+
(*_test).status = ::kernel::bindings::kunit_status_KUNIT_SUCCESS;
use ::kernel::kunit::is_test_result_ok;
assert!(is_test_result_ok(#test()));
+
+ #[cfg(CONFIG_RUST_LOCKDEP_KUNIT_DEBUG_LOCKS)]
+ {
+ let __debug_locks_ok =
+ ::kernel::bindings::debug_locks == __debug_locks_snapshot;
+ assert!(__debug_locks_ok);
+ }
}
}
});

--
2.51.2

[Malte Wechter]

Triggering a `BUG: sleeping function called from invalid context` does
not mark the unit test as failed. Add a CONFIG_RUST_TAINT_WARN_CHECK to
enable the assertion of TAINT_WARN being set during a unit test.

Signed-off-by: Malte Wechter <maltew...@gmail.com>
---

lib/kunit/Kconfig | 11 +++++++++++
rust/macros/kunit.rs | 11 +++++++++++
2 files changed, 22 insertions(+)

diff --git a/lib/kunit/Kconfig b/lib/kunit/Kconfig
index 30bac00c42ce1..4025b5b305549 100644
--- a/lib/kunit/Kconfig
+++ b/lib/kunit/Kconfig
@@ -154,5 +154,16 @@ config RUST_LOCKDEP_KUNIT_DEBUG_LOCKS

this makes it so the KUnit test does not succeed if the test assertions are

true, but a lockdep warning is triggered.

+ If unsure, say N.
+
+config RUST_KUNIT_TAINT_WARN_CHECK
+ bool "Enable extra taint assertion in KUnit tests"
+ depends on RUST

+ default n
+ help
+ Adds an extra assertion to each Rust kunit test case that asserts

+ that the kernel is not tainted. If the kernel becomes tainted with a TAINT_WARN,
+ Enabling this config marks the test as failed.

+
If unsure, say N.
endif # KUNIT
diff --git a/rust/macros/kunit.rs b/rust/macros/kunit.rs

index d1cd0349f86f0..90264ef54a3a8 100644
--- a/rust/macros/kunit.rs
+++ b/rust/macros/kunit.rs
@@ -146,6 +146,10 @@ macro_rules! assert_eq {
{
#[cfg(CONFIG_RUST_LOCKDEP_KUNIT_DEBUG_LOCKS)]

let __debug_locks_snapshot = ::kernel::bindings::debug_locks;

+ #[cfg(CONFIG_RUST_KUNIT_TAINT_WARN_CHECK)]
+ let __is_tainted_snapshot =
+ ::kernel::bindings::test_taint(::kernel::bindings::TAINT_WARN);

+

(*_test).status = ::kernel::bindings::kunit_status_KUNIT_SUCCESS;
use ::kernel::kunit::is_test_result_ok;

@@ -157,6 +161,13 @@ macro_rules! assert_eq {

::kernel::bindings::debug_locks == __debug_locks_snapshot;

assert!(__debug_locks_ok);
}
+ #[cfg(CONFIG_RUST_KUNIT_TAINT_WARN_CHECK)]
+ {
+ let __is_tainted =
+ ::kernel::bindings::test_taint(::kernel::bindings::TAINT_WARN)
+ == __is_tainted_snapshot;
+ assert!(__is_tainted);
+ }
}
}
});

--
2.51.2

[Andreas Hindborg]

Why the double underscore start?


Best regards,
Andreas Hindborg

[David Gow]

Le 18/08/2026 à 23:20, Malte Wechter a écrit :
> Add configs that enable extra assertions to be emitted to KUnit test
> cases. This makes a subset of concurrency related warnings fail unit test
> cases, and not stay as silent warnings.
>
> Signed-off-by: Malte Wechter <maltew...@gmail.com>
> ---

Hi Malte,

Thanks for sending these in: I think they're worthwhile additions to KUnit.

My preference, however, would be to have these features added to the
core KUnit implementation (in C), rather than specifically to the Rust
bindings. This way, tests written in both languages will be able to
benefit from them, rather than just tests written in Rust.

The other option, which may be better, is to have the warning and/or
lockdep code fail the current test. This would have some slightly
different tradeoffs (for example, it would only trigger if the test
thread caused the issue), but would make it easier to integrate with
warning suppression[1], which allows tests to deliberately trigger and
expect warnings:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=85347718ab0dd7ede9c3e1dcff2d604c7073df05

In that case, you'd want to look into the kunit_fail_current_test()
macro. KASAN also has a similar integration, so that KASAN failures will
fail tests:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c8c7016f50c85688d71feea2dba1bd955d5f5358

Cheers,
-- David

[Miguel Ojeda]

On Fri, Aug 21, 2026 at 11:01 AM David Gow <da...@davidgow.net> wrote:
>
> My preference, however, would be to have these features added to the
> core KUnit implementation (in C), rather than specifically to the Rust
> bindings. This way, tests written in both languages will be able to
> benefit from them, rather than just tests written in Rust.

Agreed, I was about to reply with that, i.e. if this is a feature that
is worth having, then it sounded to me like it should be in core
KUnit.

Cheers,
Miguel

[Malte Wechter]

Den fre. 21. aug. 2026 kl. 11.04 skrev Miguel Ojeda
<miguel.oje...@gmail.com>:

Sounds good, i will look at implementing this in core KUnit instead.

Best regards