mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Gow <david@davidgow.net>
To: "Malte Wechter" <maltewechter@gmail.com>,
	"Brendan Higgins" <brendan.higgins@linux.dev>,
	"Rae Moar" <raemoar63@gmail.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Boqun Feng" <boqun@kernel.org>, "Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Tamir Duberstein" <tamird@kernel.org>,
	"Alexandre Courbot" <acourbot@nvidia.com>,
	"Onur Özkan" <work@onurozkan.dev>
Cc: linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com,
	linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v2 2/2] kunit: add KUnit test to assert kernel state before KUnit suites are run
Date: Tue, 25 Aug 2026 19:00:04 +0800	[thread overview]
Message-ID: <205be33b-362d-45cb-b3a1-cadaba87b44a@davidgow.net> (raw)
In-Reply-To: <20260824-lockdep-kunit-v2-2-36a6fec9f72e@gmail.com>

Le 24/08/2026 à 21:32, Malte Wechter a écrit :
> add pre-defined KUnit test suite and test case that asserts both
> `debug_locks` and `TAINT_WARN` prior to running any (user) KUnit tests.
> This asserts integrity before tests are run.
> 
> Signed-off-by: Malte Wechter <maltewechter@gmail.com>
> ---

I'm not quite as convinced by this as I am by the first patch. While 
ensuring the state of the system is good before tests are run is useful, 
this does seem a bit heavy-handed in some respects.

This could probably use a more detailed description, particularly 
describing why such a test is useful, and why it would need to be 
implemented in a special way.

And I do think the implementation here is a bit _too_ special-cased. One 
other possibility would be to prepend this suite using 
kunit_merge_suite_sets(), so we don't need to have any special handling 
of (e.g.) the test count. This could also allow this special suite to be 
filtered out (which has both advantages and disadvantages).

It might also be nice to have this configurable independently from the 
other checks, and maybe at runtime (via a KUnit module / command-line 
parameter), particularly if this can't be filtered on. And, as before, 
this definitely needs to be documented. People need to know how to 
enable it, and where all of these extra results from tests they didn't 
enable came from.

Thoughts?

Cheers,
-- David

>   lib/kunit/executor.c |  8 +++++++-
>   lib/kunit/test.c     | 30 ++++++++++++++++++++++++++++++
>   2 files changed, 37 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/kunit/executor.c b/lib/kunit/executor.c
> index b0f8a41d61d36..0db67fe7f09f9 100644
> --- a/lib/kunit/executor.c
> +++ b/lib/kunit/executor.c
> @@ -290,9 +290,15 @@ void kunit_exec_run_tests(struct kunit_suite_set *suite_set, bool builtin)
>   	size_t num_suites = suite_set->end - suite_set->start;
>   	bool autorun = kunit_autorun();
>   
> +	#ifdef CONFIG_KUNIT_EXTRA_ASSERTS

Nit: Let's not indent the #ifdefs.

> +	size_t num_suites_plus_extra = num_suites+1;
> +	#else
> +	size_t num_suites_plus_extra = num_suites;
> +	#endif
> +

I'm not particularly happy with this way of adding an extra suite.

>   	if (autorun && (builtin || num_suites)) {
>   		pr_info("KTAP version 1\n");
> -		pr_info("1..%zu\n", num_suites);
> +		pr_info("1..%zu\n", num_suites_plus_extra);
>   	}
>   
>   	__kunit_test_suites_init(suite_set->start, num_suites, autorun);
> diff --git a/lib/kunit/test.c b/lib/kunit/test.c
> index 99773e000e1b7..e64c6d1575280 100644
> --- a/lib/kunit/test.c
> +++ b/lib/kunit/test.c
> @@ -835,6 +835,30 @@ bool kunit_enabled(void)
>   	return enable_param;
>   }
>   
> +#ifdef CONFIG_KUNIT_EXTRA_ASSERTS
> +#define DEBUG_LOCKS_OK 1
> +#define TAINT_WARN_OK 0

Not totally sold on these #defines: I think I'd prefer to just have the 
literal 1/0.

> +
> +static void pre_kunit_assert(struct kunit *test)
> +{
> +	KUNIT_EXPECT_EQ_MSG(test, debug_locks, DEBUG_LOCKS_OK,
> +		"debug_locks are off before any test ran");
> +	KUNIT_EXPECT_EQ_MSG(test, test_taint(TAINT_WARN), TAINT_WARN_OK,
> +		"kernel already TAINT_WARN tainted before any test ran");
> +}

If we are going to generate a special suite, let's have the taint and 
lockdep checks as separate tests.

This would also make it easier to have them be configurable separately.

> +
> +static struct kunit_case pre_kunit_assert_cases[] = {
> +	KUNIT_CASE(pre_kunit_assert),
> +	{}
> +};
> +
> +static struct kunit_suite pre_kunit_assert_clean_state_suite = {
> +	.name = "pre_kunit_extra_asserts",

I think we could probably find a better name for this. 
"initial_system_state" or similar might be better?

> +	.test_cases = pre_kunit_assert_cases,
> +};
> +
> +#endif /* CONFIG_RUST_KUNIT_EXTRA_ASSERTS */
> +
>   int __kunit_test_suites_init(struct kunit_suite * const * const suites, int num_suites,
>   			     bool run_tests)
>   {
> @@ -857,6 +881,12 @@ int __kunit_test_suites_init(struct kunit_suite * const * const suites, int num_
>   	}
>   	static_branch_inc(&kunit_running);
>   
> +	#ifdef CONFIG_KUNIT_EXTRA_ASSERTS
> +	kunit_init_suite(&pre_kunit_assert_clean_state_suite);
> +	if (run_tests)
> +		kunit_run_tests(&pre_kunit_assert_clean_state_suite);
> +	#endif
> +
>   	for (i = 0; i < num_suites; i++) {
>   		kunit_init_suite(suites[i]);
>   		if (run_tests)
> 


  reply	other threads:[~2026-08-25 11:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-24 13:32 [PATCH v2 0/2] kunit: add optional assertions to catch taint and lockdep warnings Malte Wechter
2026-08-24 13:32 ` [PATCH v2 1/2] kunit: add extra assertions to KUnit test cases Malte Wechter
2026-08-25 11:00   ` David Gow
2026-09-01  9:19     ` Malte Wechter
2026-08-24 13:32 ` [PATCH v2 2/2] kunit: add KUnit test to assert kernel state before KUnit suites are run Malte Wechter
2026-08-25 11:00   ` David Gow [this message]
2026-09-01 11:02     ` Malte Wechter
2026-10-06  6:47       ` David Gow
2026-10-06  9:46         ` Malte Wechter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=205be33b-362d-45cb-b3a1-cadaba87b44a@davidgow.net \
    --to=david@davidgow.net \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun@kernel.org \
    --cc=brendan.higgins@linux.dev \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=gary@garyguo.net \
    --cc=kunit-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=maltewechter@gmail.com \
    --cc=ojeda@kernel.org \
    --cc=raemoar63@gmail.com \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tamird@kernel.org \
    --cc=tmgross@umich.edu \
    --cc=work@onurozkan.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®