[PATCH v3 0/3] kunit: Expose some built-in features to modules

[PATCH v3 0/3] kunit: Expose some built-in features to modules

[Janusz Krzysztofik]

Submit the top-level headers also from the kunit test module notifier
initialization callback, so external tools that are parsing dmesg for
kunit test output are able to tell how many test suites should be expected
and whether to continue parsing after complete output from the first test
suite is collected.

Extend kunit module notifier initialization callback with a processing
path for only listing the tests provided by a module if the kunit action
parameter is set to "list", so external tools can obtain a list of test
cases to be executed in advance and can make a better job on assigning
kernel messages interleaved with kunit output to specific tests.

Use test filtering functions in kunit module notifier callback functions,
so external tools are able to execute individual test cases from kunit
test modules in order to still better isolate their potential impact on
kernel messages that appear interleaved with output from other tests.

v3: Fix CONFIG_GLOB, required by filtering fuctions, not selected when
    building as a module.
v2: Fix new name of a structure moved to kunit namespace not updated
    across all uses.

Janusz Krzysztofik (3):
  kunit: Report the count of test suites in a module
  kunit: Make 'list' action available to kunit test modules
  kunit: Allow kunit test modules to use test filtering

 include/kunit/test.h | 14 +++++++++++
 lib/kunit/Kconfig    |  2 +-
 lib/kunit/executor.c | 57 +++++++++++++++++++++++++-------------------
 lib/kunit/test.c     | 57 +++++++++++++++++++++++++++++++++++++++++++-
 4 files changed, 104 insertions(+), 26 deletions(-)

-- 
2.41.0

[PATCH v3 1/3] kunit: Report the count of test suites in a module

[Janusz Krzysztofik]

According to KTAP specification[1], results should always start from a
header that provides a TAP protocol version, followed by a test plan with
a count of items to be executed.  That pattern should be followed at each
nesting level.  In the current implementation of the top-most, i.e., test
suite level, those rules apply only for test suites built into the kernel,
executed and reported on boot.  Results submitted to dmesg from kunit test
modules loaded later are missing those top-level headers.

As a consequence, if a kunit test module provides more than one test suite
then, without the top level test plan, external tools that are parsing
dmesg for kunit test output are not able to tell how many test suites
should be expected and whether to continue parsing after complete output
from the first test suite is collected.

Submit the top-level headers also from the kunit test module notifier
initialization callback.

[1] https://docs.kernel.org/dev-tools/ktap.html#

Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
---
 lib/kunit/test.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/lib/kunit/test.c b/lib/kunit/test.c
index 84e4666555c94..a29ca1acc4d81 100644
--- a/lib/kunit/test.c
+++ b/lib/kunit/test.c
@@ -729,6 +729,11 @@ EXPORT_SYMBOL_GPL(__kunit_test_suites_exit);
 #ifdef CONFIG_MODULES
 static void kunit_module_init(struct module *mod)
 {
+	if (mod->num_kunit_suites > 0) {
+		pr_info("KTAP version 1\n");
+		pr_info("1..%d\n", mod->num_kunit_suites);
+	}
+
 	__kunit_test_suites_init(mod->kunit_suites, mod->num_kunit_suites);
 }
 
-- 
2.41.0

Re: [PATCH v3 1/3] kunit: Report the count of test suites in a module

[Mauro Carvalho Chehab]

Em Mon, 31 Jul 2023 16:10:23 +0200
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> escreveu:

> According to KTAP specification[1], results should always start from a
> header that provides a TAP protocol version, followed by a test plan with
> a count of items to be executed.  That pattern should be followed at each
> nesting level.  In the current implementation of the top-most, i.e., test
> suite level, those rules apply only for test suites built into the kernel,
> executed and reported on boot.  Results submitted to dmesg from kunit test
> modules loaded later are missing those top-level headers.
> 
> As a consequence, if a kunit test module provides more than one test suite
> then, without the top level test plan, external tools that are parsing
> dmesg for kunit test output are not able to tell how many test suites
> should be expected and whether to continue parsing after complete output
> from the first test suite is collected.
> 
> Submit the top-level headers also from the kunit test module notifier
> initialization callback.
> 
> [1] https://docs.kernel.org/dev-tools/ktap.html#
> 
> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> ---
>  lib/kunit/test.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/lib/kunit/test.c b/lib/kunit/test.c
> index 84e4666555c94..a29ca1acc4d81 100644
> --- a/lib/kunit/test.c
> +++ b/lib/kunit/test.c
> @@ -729,6 +729,11 @@ EXPORT_SYMBOL_GPL(__kunit_test_suites_exit);
>  #ifdef CONFIG_MODULES
>  static void kunit_module_init(struct module *mod)
>  {
> +	if (mod->num_kunit_suites > 0) {
> +		pr_info("KTAP version 1\n");
> +		pr_info("1..%d\n", mod->num_kunit_suites);
> +	}
> +
>  	__kunit_test_suites_init(mod->kunit_suites, mod->num_kunit_suites);
>  }

IMO, the best would be instead to export kunit_exec_run_tests() and
use it here too.

Except for the nit, LGTM.


Thanks,
Mauro

Re: [PATCH v3 1/3] kunit: Report the count of test suites in a module

[Janusz Krzysztofik]

Hi Mauro,

Thanks for review.

On Tuesday, 1 August 2023 15:17:11 CEST Mauro Carvalho Chehab wrote:
> Em Mon, 31 Jul 2023 16:10:23 +0200
> Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> escreveu:
> 
> > According to KTAP specification[1], results should always start from a
> > header that provides a TAP protocol version, followed by a test plan with
> > a count of items to be executed.  That pattern should be followed at each
> > nesting level.  In the current implementation of the top-most, i.e., test
> > suite level, those rules apply only for test suites built into the kernel,
> > executed and reported on boot.  Results submitted to dmesg from kunit test
> > modules loaded later are missing those top-level headers.
> > 
> > As a consequence, if a kunit test module provides more than one test suite
> > then, without the top level test plan, external tools that are parsing
> > dmesg for kunit test output are not able to tell how many test suites
> > should be expected and whether to continue parsing after complete output
> > from the first test suite is collected.
> > 
> > Submit the top-level headers also from the kunit test module notifier
> > initialization callback.
> > 
> > [1] https://docs.kernel.org/dev-tools/ktap.html#
> > 
> > Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> > ---
> >  lib/kunit/test.c | 5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/lib/kunit/test.c b/lib/kunit/test.c
> > index 84e4666555c94..a29ca1acc4d81 100644
> > --- a/lib/kunit/test.c
> > +++ b/lib/kunit/test.c
> > @@ -729,6 +729,11 @@ EXPORT_SYMBOL_GPL(__kunit_test_suites_exit);
> >  #ifdef CONFIG_MODULES
> >  static void kunit_module_init(struct module *mod)
> >  {
> > +	if (mod->num_kunit_suites > 0) {
> > +		pr_info("KTAP version 1\n");
> > +		pr_info("1..%d\n", mod->num_kunit_suites);
> > +	}
> > +
> >  	__kunit_test_suites_init(mod->kunit_suites, mod->num_kunit_suites);
> >  }
> 
> IMO, the best would be instead to export kunit_exec_run_tests() and
> use it here too.

I was considering a similar approach, i.e., moving those two pr_info() lines 
from built-in only kunit_exec_run_tests() to __kunit_test_suites_init() which 
is common to both built-in and modular paths, but please note that with kunit 
built in, an empty test plan "1..0" is now reported on boot, while we don't 
want similar reports to appear on loading modules that don't provide any kunit 
tests.  Then, inside either your exported kunit_exec_run_tests() or my 
__kunit_test_suites_init(), we would have to check somehow if it has been 
called from a module notifier initialization callback, and that seemed to me 
too much complicated and less clean than what I've proposed: keep using 
unmodified kunit_exec_run_tests() in built-in and updated kunit_module_init() 
in modular processing path.
Dropping the empty "1..0" test plan from boot messages would mean an ABI 
change, I believe, which I'd rather avoid adding to the scope of this patch as 
not required.

Thanks,
Janusz
 
> 
> Except for the nit, LGTM.
> 
> 
> Thanks,
> Mauro
> 

Re: [PATCH v3 1/3] kunit: Report the count of test suites in a module

[Rae Moar]

On Mon, Jul 31, 2023 at 10:12 AM Janusz Krzysztofik
<janusz.krzysztofik@linux.intel.com> wrote:
>
> According to KTAP specification[1], results should always start from a
> header that provides a TAP protocol version, followed by a test plan with
> a count of items to be executed.  That pattern should be followed at each
> nesting level.  In the current implementation of the top-most, i.e., test
> suite level, those rules apply only for test suites built into the kernel,
> executed and reported on boot.  Results submitted to dmesg from kunit test
> modules loaded later are missing those top-level headers.
>
> As a consequence, if a kunit test module provides more than one test suite
> then, without the top level test plan, external tools that are parsing
> dmesg for kunit test output are not able to tell how many test suites
> should be expected and whether to continue parsing after complete output
> from the first test suite is collected.
>
> Submit the top-level headers also from the kunit test module notifier
> initialization callback.
>
> [1] https://docs.kernel.org/dev-tools/ktap.html#
>
> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> ---

Hi!

I think this is a really great idea to improve the KTAP compatibility
for module output. I do agree with Mauro and I wonder if this could be
replaced with using kunit_exec_run_tests. However, if the output of
1..0 for a module with no KUnit tests run is not wanted, I am ok with
this change as is.

LGTM.

Tested-by: Rae Moar <rmoar@google.com>

-Rae

>  lib/kunit/test.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/lib/kunit/test.c b/lib/kunit/test.c
> index 84e4666555c94..a29ca1acc4d81 100644
> --- a/lib/kunit/test.c
> +++ b/lib/kunit/test.c
> @@ -729,6 +729,11 @@ EXPORT_SYMBOL_GPL(__kunit_test_suites_exit);
>  #ifdef CONFIG_MODULES
>  static void kunit_module_init(struct module *mod)
>  {
> +       if (mod->num_kunit_suites > 0) {
> +               pr_info("KTAP version 1\n");
> +               pr_info("1..%d\n", mod->num_kunit_suites);
> +       }
> +
>         __kunit_test_suites_init(mod->kunit_suites, mod->num_kunit_suites);
>  }
>
> --
> 2.41.0
>
> --
> You received this message because you are subscribed to the Google Groups "KUnit Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kunit-dev+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kunit-dev/20230731141021.2854827-6-janusz.krzysztofik%40linux.intel.com.

Re: [PATCH v3 1/3] kunit: Report the count of test suites in a module

[Janusz Krzysztofik]

Hi Rae,

On Thursday, 3 August 2023 22:57:43 CEST Rae Moar wrote:
> On Mon, Jul 31, 2023 at 10:12 AM Janusz Krzysztofik
> <janusz.krzysztofik@linux.intel.com> wrote:
> >
> > According to KTAP specification[1], results should always start from a
> > header that provides a TAP protocol version, followed by a test plan with
> > a count of items to be executed.  That pattern should be followed at each
> > nesting level.  In the current implementation of the top-most, i.e., test
> > suite level, those rules apply only for test suites built into the kernel,
> > executed and reported on boot.  Results submitted to dmesg from kunit test
> > modules loaded later are missing those top-level headers.
> >
> > As a consequence, if a kunit test module provides more than one test suite
> > then, without the top level test plan, external tools that are parsing
> > dmesg for kunit test output are not able to tell how many test suites
> > should be expected and whether to continue parsing after complete output
> > from the first test suite is collected.
> >
> > Submit the top-level headers also from the kunit test module notifier
> > initialization callback.
> >
> > [1] https://docs.kernel.org/dev-tools/ktap.html#
> >
> > Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> > ---
> 
> Hi!
> 
> I think this is a really great idea to improve the KTAP compatibility
> for module output. I do agree with Mauro and I wonder if this could be
> replaced with using kunit_exec_run_tests. However, if the output of
> 1..0 for a module with no KUnit tests run is not wanted, 

I do believe we really don't want that.  As soon as kunit framework registers 
its notifier callbacks, those callbacks are executed by generic module 
handling code on load / unload of every module, not only those providing kunit 
tests.  If our module initialization callback called unmodified 
kunit_exec_run_tests() that deliberately prints these two lines 
unconditionally:

	KTAP version 1
	1..n

then there would be a lot of unnecessary noise.

To avoid that noise, I decided to teach the callback itself to display the 
header with the number of test suits provided by the module before processing 
them if there is at least one, and be silent otherwise.  But since both you 
and Mauro think that kunit_exec_run_tests() should be reused, I can do that by 
moving that logic to kunit_exec_run_tests() and passing an additional flag 
that controls that logic from kunit_module_init() to kunit_exec_run_tests().  
Would that approach be more acceptable?

> I am ok with
> this change as is.
> 
> LGTM.
> 
> Tested-by: Rae Moar <rmoar@google.com>

Thank you for testing.

Janusz

> 
> -Rae
> 
> >  lib/kunit/test.c | 5 +++++
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/lib/kunit/test.c b/lib/kunit/test.c
> > index 84e4666555c94..a29ca1acc4d81 100644
> > --- a/lib/kunit/test.c
> > +++ b/lib/kunit/test.c
> > @@ -729,6 +729,11 @@ EXPORT_SYMBOL_GPL(__kunit_test_suites_exit);
> >  #ifdef CONFIG_MODULES
> >  static void kunit_module_init(struct module *mod)
> >  {
> > +       if (mod->num_kunit_suites > 0) {
> > +               pr_info("KTAP version 1\n");
> > +               pr_info("1..%d\n", mod->num_kunit_suites);
> > +       }
> > +
> >         __kunit_test_suites_init(mod->kunit_suites, mod-
>num_kunit_suites);
> >  }
> >
> > --
> > 2.41.0
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
"KUnit Development" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
email to kunit-dev+unsubscribe@googlegroups.com.
> > To view this discussion on the web visit https://groups.google.com/d/
msgid/kunit-dev/20230731141021.2854827-6-janusz.krzysztofik%40linux.intel.com.
> 

[PATCH v3 2/3] kunit: Make 'list' action available to kunit test modules

[Janusz Krzysztofik]

Results from kunit tests reported via dmesg may be interleaved with other
kernel messages.  When parsing dmesg for modular kunit results in real
time, external tools, e.g., Intel GPU tools (IGT), may want to insert
their own test name markers into dmesg at the start of each test, before
any kernel message related to that test appears there, so existing upper
level test result parsers have no doubt which test to blame for a specific
kernel message.  Unfortunately, kunit reports names of tests only at their
completion (with the exeption of a not standarized "# Subtest: <name>"
header above a test plan of each test suite or parametrized test).

External tools could be able to insert their own "start of the test"
markers with test names included if they new those names in advance.
Test names could be learned from a list if provided by a kunit test
module.

There exists a feature of listing kunit tests without actually executing
them, but it is now limited to configurations with the kunit module built
in and covers only built-in tests, already available at boot time.
Moreover, switching from list to normal mode requires reboot.  If that
feature was also available when kunit is built as a module, userspace
could load the module with action=list parameter, load some kunit test
modules they are interested in and learn about the list of tests provided
by those modules, then unload them, reload the kunit module in normal mode
and execute the tests with their lists already known.

Extend kunit module notifier initialization callback with a processing
path for only listing the tests provided by a module if the kunit action
parameter is set to "list".  For ease of use, submit the list in the
format of a standard KTAP report, with SKIP result from each test case,
giving "list mode" as the reason for skipping.  For each test suite
provided by a kunit test module, make such list of its test cases also
available via kunit debugfs for the lifetime of the module.  For user
convenience, make the kunit.action parameter visible in sysfs.

Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
---
 include/kunit/test.h |  1 +
 lib/kunit/executor.c | 19 +++++++++++++------
 lib/kunit/test.c     | 30 +++++++++++++++++++++++++++++-
 3 files changed, 43 insertions(+), 7 deletions(-)

diff --git a/include/kunit/test.h b/include/kunit/test.h
index 23120d50499ef..6d693f21a4833 100644
--- a/include/kunit/test.h
+++ b/include/kunit/test.h
@@ -237,6 +237,7 @@ static inline void kunit_set_failure(struct kunit *test)
 }
 
 bool kunit_enabled(void);
+const char *kunit_action(void);
 
 void kunit_init_test(struct kunit *test, const char *name, char *log);
 
diff --git a/lib/kunit/executor.c b/lib/kunit/executor.c
index 74982b83707ca..d1c0616569dfd 100644
--- a/lib/kunit/executor.c
+++ b/lib/kunit/executor.c
@@ -12,19 +12,26 @@
 extern struct kunit_suite * const __kunit_suites_start[];
 extern struct kunit_suite * const __kunit_suites_end[];
 
+static char *action_param;
+
+module_param_named(action, action_param, charp, 0400);
+MODULE_PARM_DESC(action,
+		 "Changes KUnit executor behavior, valid values are:\n"
+		 "<none>: run the tests like normal\n"
+		 "'list' to list test names instead of running them.\n");
+
+const char *kunit_action(void)
+{
+	return action_param;
+}
+
 #if IS_BUILTIN(CONFIG_KUNIT)
 
 static char *filter_glob_param;
-static char *action_param;
 
 module_param_named(filter_glob, filter_glob_param, charp, 0);
 MODULE_PARM_DESC(filter_glob,
 		"Filter which KUnit test suites/tests run at boot-time, e.g. list* or list*.*del_test");
-module_param_named(action, action_param, charp, 0);
-MODULE_PARM_DESC(action,
-		 "Changes KUnit executor behavior, valid values are:\n"
-		 "<none>: run the tests like normal\n"
-		 "'list' to list test names instead of running them.\n");
 
 /* glob_match() needs NULL terminated strings, so we need a copy of filter_glob_param. */
 struct kunit_test_filter {
diff --git a/lib/kunit/test.c b/lib/kunit/test.c
index a29ca1acc4d81..413d9fd364a8d 100644
--- a/lib/kunit/test.c
+++ b/lib/kunit/test.c
@@ -674,6 +674,27 @@ int kunit_run_tests(struct kunit_suite *suite)
 }
 EXPORT_SYMBOL_GPL(kunit_run_tests);
 
+static void kunit_list_suite(struct kunit_suite *suite)
+{
+	struct kunit_case *test_case;
+
+	kunit_print_suite_start(suite);
+
+	kunit_suite_for_each_test_case(suite, test_case) {
+		struct kunit test = { .param_value = NULL, .param_index = 0 };
+
+		kunit_init_test(&test, test_case->name, test_case->log);
+
+		kunit_print_ok_not_ok(&test, true, KUNIT_SKIPPED,
+				      kunit_test_case_num(suite, test_case),
+				      test_case->name, "list mode");
+	}
+
+	kunit_print_ok_not_ok((void *)suite, false, KUNIT_SKIPPED,
+			      kunit_suite_counter++,
+			      suite->name, "list mode");
+}
+
 static void kunit_init_suite(struct kunit_suite *suite)
 {
 	kunit_debugfs_create_suite(suite);
@@ -688,6 +709,7 @@ bool kunit_enabled(void)
 
 int __kunit_test_suites_init(struct kunit_suite * const * const suites, int num_suites)
 {
+	const char *action = kunit_action();
 	unsigned int i;
 
 	if (!kunit_enabled() && num_suites > 0) {
@@ -699,7 +721,13 @@ int __kunit_test_suites_init(struct kunit_suite * const * const suites, int num_
 
 	for (i = 0; i < num_suites; i++) {
 		kunit_init_suite(suites[i]);
-		kunit_run_tests(suites[i]);
+
+		if (!action)
+			kunit_run_tests(suites[i]);
+		else if (!strcmp(action, "list"))
+			kunit_list_suite(suites[i]);
+		else
+			pr_err("kunit: unknown action '%s'\n", action);
 	}
 
 	static_branch_dec(&kunit_running);
-- 
2.41.0

Re: [PATCH v3 2/3] kunit: Make 'list' action available to kunit test modules

[Mauro Carvalho Chehab]

Em Mon, 31 Jul 2023 16:10:24 +0200
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> escreveu:

> Results from kunit tests reported via dmesg may be interleaved with other
> kernel messages.  When parsing dmesg for modular kunit results in real
> time, external tools, e.g., Intel GPU tools (IGT), may want to insert
> their own test name markers into dmesg at the start of each test, before
> any kernel message related to that test appears there, so existing upper
> level test result parsers have no doubt which test to blame for a specific
> kernel message.  Unfortunately, kunit reports names of tests only at their
> completion (with the exeption of a not standarized "# Subtest: <name>"
> header above a test plan of each test suite or parametrized test).
> 
> External tools could be able to insert their own "start of the test"
> markers with test names included if they new those names in advance.
> Test names could be learned from a list if provided by a kunit test
> module.
> 
> There exists a feature of listing kunit tests without actually executing
> them, but it is now limited to configurations with the kunit module built
> in and covers only built-in tests, already available at boot time.
> Moreover, switching from list to normal mode requires reboot.  If that
> feature was also available when kunit is built as a module, userspace
> could load the module with action=list parameter, load some kunit test
> modules they are interested in and learn about the list of tests provided
> by those modules, then unload them, reload the kunit module in normal mode
> and execute the tests with their lists already known.
> 
> Extend kunit module notifier initialization callback with a processing
> path for only listing the tests provided by a module if the kunit action
> parameter is set to "list".  For ease of use, submit the list in the
> format of a standard KTAP report, with SKIP result from each test case,
> giving "list mode" as the reason for skipping.  For each test suite
> provided by a kunit test module, make such list of its test cases also
> available via kunit debugfs for the lifetime of the module.  For user
> convenience, make the kunit.action parameter visible in sysfs.

It sounds interesting to have a modprobe option to just list the
tests without excecuting.

> 
> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> ---
>  include/kunit/test.h |  1 +
>  lib/kunit/executor.c | 19 +++++++++++++------
>  lib/kunit/test.c     | 30 +++++++++++++++++++++++++++++-
>  3 files changed, 43 insertions(+), 7 deletions(-)
> 
> diff --git a/include/kunit/test.h b/include/kunit/test.h
> index 23120d50499ef..6d693f21a4833 100644
> --- a/include/kunit/test.h
> +++ b/include/kunit/test.h
> @@ -237,6 +237,7 @@ static inline void kunit_set_failure(struct kunit *test)
>  }
>  
>  bool kunit_enabled(void);
> +const char *kunit_action(void);
>  
>  void kunit_init_test(struct kunit *test, const char *name, char *log);
>  
> diff --git a/lib/kunit/executor.c b/lib/kunit/executor.c
> index 74982b83707ca..d1c0616569dfd 100644
> --- a/lib/kunit/executor.c
> +++ b/lib/kunit/executor.c
> @@ -12,19 +12,26 @@
>  extern struct kunit_suite * const __kunit_suites_start[];
>  extern struct kunit_suite * const __kunit_suites_end[];
>  
> +static char *action_param;
> +
> +module_param_named(action, action_param, charp, 0400);
> +MODULE_PARM_DESC(action,
> +		 "Changes KUnit executor behavior, valid values are:\n"
> +		 "<none>: run the tests like normal\n"
> +		 "'list' to list test names instead of running them.\n");

Help message sounded confusing. What about adding a boolean modprobe
parameter, like "list_tests"?

> +
> +const char *kunit_action(void)
> +{
> +	return action_param;
> +}
> +
>  #if IS_BUILTIN(CONFIG_KUNIT)
>  
>  static char *filter_glob_param;
> -static char *action_param;
>  
>  module_param_named(filter_glob, filter_glob_param, charp, 0);
>  MODULE_PARM_DESC(filter_glob,
>  		"Filter which KUnit test suites/tests run at boot-time, e.g. list* or list*.*del_test");
> -module_param_named(action, action_param, charp, 0);
> -MODULE_PARM_DESC(action,
> -		 "Changes KUnit executor behavior, valid values are:\n"
> -		 "<none>: run the tests like normal\n"
> -		 "'list' to list test names instead of running them.\n");
>  
>  /* glob_match() needs NULL terminated strings, so we need a copy of filter_glob_param. */
>  struct kunit_test_filter {
> diff --git a/lib/kunit/test.c b/lib/kunit/test.c
> index a29ca1acc4d81..413d9fd364a8d 100644
> --- a/lib/kunit/test.c
> +++ b/lib/kunit/test.c
> @@ -674,6 +674,27 @@ int kunit_run_tests(struct kunit_suite *suite)
>  }
>  EXPORT_SYMBOL_GPL(kunit_run_tests);
>  
> +static void kunit_list_suite(struct kunit_suite *suite)
> +{
> +	struct kunit_case *test_case;
> +
> +	kunit_print_suite_start(suite);
> +
> +	kunit_suite_for_each_test_case(suite, test_case) {
> +		struct kunit test = { .param_value = NULL, .param_index = 0 };
> +
> +		kunit_init_test(&test, test_case->name, test_case->log);
> +
> +		kunit_print_ok_not_ok(&test, true, KUNIT_SKIPPED,
> +				      kunit_test_case_num(suite, test_case),
> +				      test_case->name, "list mode");
> +	}
> +
> +	kunit_print_ok_not_ok((void *)suite, false, KUNIT_SKIPPED,
> +			      kunit_suite_counter++,
> +			      suite->name, "list mode");
> +}
> +
>  static void kunit_init_suite(struct kunit_suite *suite)
>  {
>  	kunit_debugfs_create_suite(suite);
> @@ -688,6 +709,7 @@ bool kunit_enabled(void)
>  
>  int __kunit_test_suites_init(struct kunit_suite * const * const suites, int num_suites)
>  {
> +	const char *action = kunit_action();
>  	unsigned int i;
>  
>  	if (!kunit_enabled() && num_suites > 0) {
> @@ -699,7 +721,13 @@ int __kunit_test_suites_init(struct kunit_suite * const * const suites, int num_
>  
>  	for (i = 0; i < num_suites; i++) {
>  		kunit_init_suite(suites[i]);
> -		kunit_run_tests(suites[i]);
> +
> +		if (!action)
> +			kunit_run_tests(suites[i]);
> +		else if (!strcmp(action, "list"))
> +			kunit_list_suite(suites[i]);
> +		else
> +			pr_err("kunit: unknown action '%s'\n", action);
>  	}
>  
>  	static_branch_dec(&kunit_running);

The remaining code LGTM.


Thanks,
Mauro

Re: [PATCH v3 2/3] kunit: Make 'list' action available to kunit test modules

[Janusz Krzysztofik]

Hi Mauro,

On Tuesday, 1 August 2023 15:21:20 CEST Mauro Carvalho Chehab wrote:
> Em Mon, 31 Jul 2023 16:10:24 +0200
> Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> escreveu:
> 
> > Results from kunit tests reported via dmesg may be interleaved with other
> > kernel messages.  When parsing dmesg for modular kunit results in real
> > time, external tools, e.g., Intel GPU tools (IGT), may want to insert
> > their own test name markers into dmesg at the start of each test, before
> > any kernel message related to that test appears there, so existing upper
> > level test result parsers have no doubt which test to blame for a specific
> > kernel message.  Unfortunately, kunit reports names of tests only at their
> > completion (with the exeption of a not standarized "# Subtest: <name>"
> > header above a test plan of each test suite or parametrized test).
> > 
> > External tools could be able to insert their own "start of the test"
> > markers with test names included if they new those names in advance.
> > Test names could be learned from a list if provided by a kunit test
> > module.
> > 
> > There exists a feature of listing kunit tests without actually executing
> > them, but it is now limited to configurations with the kunit module built
> > in and covers only built-in tests, already available at boot time.
> > Moreover, switching from list to normal mode requires reboot.  If that
> > feature was also available when kunit is built as a module, userspace
> > could load the module with action=list parameter, load some kunit test
> > modules they are interested in and learn about the list of tests provided
> > by those modules, then unload them, reload the kunit module in normal mode
> > and execute the tests with their lists already known.
> > 
> > Extend kunit module notifier initialization callback with a processing
> > path for only listing the tests provided by a module if the kunit action
> > parameter is set to "list".  For ease of use, submit the list in the
> > format of a standard KTAP report, with SKIP result from each test case,
> > giving "list mode" as the reason for skipping.  For each test suite
> > provided by a kunit test module, make such list of its test cases also
> > available via kunit debugfs for the lifetime of the module.  For user
> > convenience, make the kunit.action parameter visible in sysfs.
> 
> It sounds interesting to have a modprobe option to just list the
> tests without excecuting.
> 
> > 
> > Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> > ---
> >  include/kunit/test.h |  1 +
> >  lib/kunit/executor.c | 19 +++++++++++++------
> >  lib/kunit/test.c     | 30 +++++++++++++++++++++++++++++-
> >  3 files changed, 43 insertions(+), 7 deletions(-)
> > 
> > diff --git a/include/kunit/test.h b/include/kunit/test.h
> > index 23120d50499ef..6d693f21a4833 100644
> > --- a/include/kunit/test.h
> > +++ b/include/kunit/test.h
> > @@ -237,6 +237,7 @@ static inline void kunit_set_failure(struct kunit *test)
> >  }
> >  
> >  bool kunit_enabled(void);
> > +const char *kunit_action(void);
> >  
> >  void kunit_init_test(struct kunit *test, const char *name, char *log);
> >  
> > diff --git a/lib/kunit/executor.c b/lib/kunit/executor.c
> > index 74982b83707ca..d1c0616569dfd 100644
> > --- a/lib/kunit/executor.c
> > +++ b/lib/kunit/executor.c
> > @@ -12,19 +12,26 @@
> >  extern struct kunit_suite * const __kunit_suites_start[];
> >  extern struct kunit_suite * const __kunit_suites_end[];
> >  
> > +static char *action_param;
> > +
> > +module_param_named(action, action_param, charp, 0400);
> > +MODULE_PARM_DESC(action,
> > +		 "Changes KUnit executor behavior, valid values are:\n"
> > +		 "<none>: run the tests like normal\n"
> > +		 "'list' to list test names instead of running them.\n");
> 
> Help message sounded confusing. What about adding a boolean modprobe
> parameter, like "list_tests"?

While the above lines may look like a new code that introduced a new module 
parameter at a first glance, please note that's a chunk of the existing code, 
only moved out of #if IS_BUILTIN(CONFIG_KUNIT) section below.
Having that clarified, do you mean adding a new module parameter that 
effectively replicates the function of the existing built-in only action=list 
parameter but is available also for modular kunit?  Or do you mean replacing 
the existing action=list parameter completely with the new one?  If the latter 
then that would mean a change to the existing ABI, and I'd rather not add it 
to the scope of this change as not required.

Thanks,
Janusz

> 
> > +
> > +const char *kunit_action(void)
> > +{
> > +	return action_param;
> > +}
> > +
> >  #if IS_BUILTIN(CONFIG_KUNIT)
> >  
> >  static char *filter_glob_param;
> > -static char *action_param;
> >  
> >  module_param_named(filter_glob, filter_glob_param, charp, 0);
> >  MODULE_PARM_DESC(filter_glob,
> >  		"Filter which KUnit test suites/tests run at boot-time, e.g. list* or list*.*del_test");
> > -module_param_named(action, action_param, charp, 0);
> > -MODULE_PARM_DESC(action,
> > -		 "Changes KUnit executor behavior, valid values are:\n"
> > -		 "<none>: run the tests like normal\n"
> > -		 "'list' to list test names instead of running them.\n");
> >  
> >  /* glob_match() needs NULL terminated strings, so we need a copy of filter_glob_param. */
> >  struct kunit_test_filter {
> > diff --git a/lib/kunit/test.c b/lib/kunit/test.c
> > index a29ca1acc4d81..413d9fd364a8d 100644
> > --- a/lib/kunit/test.c
> > +++ b/lib/kunit/test.c
> > @@ -674,6 +674,27 @@ int kunit_run_tests(struct kunit_suite *suite)
> >  }
> >  EXPORT_SYMBOL_GPL(kunit_run_tests);
> >  
> > +static void kunit_list_suite(struct kunit_suite *suite)
> > +{
> > +	struct kunit_case *test_case;
> > +
> > +	kunit_print_suite_start(suite);
> > +
> > +	kunit_suite_for_each_test_case(suite, test_case) {
> > +		struct kunit test = { .param_value = NULL, .param_index = 0 };
> > +
> > +		kunit_init_test(&test, test_case->name, test_case->log);
> > +
> > +		kunit_print_ok_not_ok(&test, true, KUNIT_SKIPPED,
> > +				      kunit_test_case_num(suite, test_case),
> > +				      test_case->name, "list mode");
> > +	}
> > +
> > +	kunit_print_ok_not_ok((void *)suite, false, KUNIT_SKIPPED,
> > +			      kunit_suite_counter++,
> > +			      suite->name, "list mode");
> > +}
> > +
> >  static void kunit_init_suite(struct kunit_suite *suite)
> >  {
> >  	kunit_debugfs_create_suite(suite);
> > @@ -688,6 +709,7 @@ bool kunit_enabled(void)
> >  
> >  int __kunit_test_suites_init(struct kunit_suite * const * const suites, int num_suites)
> >  {
> > +	const char *action = kunit_action();
> >  	unsigned int i;
> >  
> >  	if (!kunit_enabled() && num_suites > 0) {
> > @@ -699,7 +721,13 @@ int __kunit_test_suites_init(struct kunit_suite * const * const suites, int num_
> >  
> >  	for (i = 0; i < num_suites; i++) {
> >  		kunit_init_suite(suites[i]);
> > -		kunit_run_tests(suites[i]);
> > +
> > +		if (!action)
> > +			kunit_run_tests(suites[i]);
> > +		else if (!strcmp(action, "list"))
> > +			kunit_list_suite(suites[i]);
> > +		else
> > +			pr_err("kunit: unknown action '%s'\n", action);
> >  	}
> >  
> >  	static_branch_dec(&kunit_running);
> 
> The remaining code LGTM.
> 
> 
> Thanks,
> Mauro
> 

Re: [PATCH v3 2/3] kunit: Make 'list' action available to kunit test modules

[Rae Moar]

On Mon, Jul 31, 2023 at 10:12 AM Janusz Krzysztofik
<janusz.krzysztofik@linux.intel.com> wrote:
>
> Results from kunit tests reported via dmesg may be interleaved with other
> kernel messages.  When parsing dmesg for modular kunit results in real
> time, external tools, e.g., Intel GPU tools (IGT), may want to insert
> their own test name markers into dmesg at the start of each test, before
> any kernel message related to that test appears there, so existing upper
> level test result parsers have no doubt which test to blame for a specific
> kernel message.  Unfortunately, kunit reports names of tests only at their
> completion (with the exeption of a not standarized "# Subtest: <name>"
> header above a test plan of each test suite or parametrized test).
>
> External tools could be able to insert their own "start of the test"
> markers with test names included if they new those names in advance.
> Test names could be learned from a list if provided by a kunit test
> module.
>
> There exists a feature of listing kunit tests without actually executing
> them, but it is now limited to configurations with the kunit module built
> in and covers only built-in tests, already available at boot time.
> Moreover, switching from list to normal mode requires reboot.  If that
> feature was also available when kunit is built as a module, userspace
> could load the module with action=list parameter, load some kunit test
> modules they are interested in and learn about the list of tests provided
> by those modules, then unload them, reload the kunit module in normal mode
> and execute the tests with their lists already known.
>
> Extend kunit module notifier initialization callback with a processing
> path for only listing the tests provided by a module if the kunit action
> parameter is set to "list".  For ease of use, submit the list in the
> format of a standard KTAP report, with SKIP result from each test case,
> giving "list mode" as the reason for skipping.  For each test suite
> provided by a kunit test module, make such list of its test cases also
> available via kunit debugfs for the lifetime of the module.  For user
> convenience, make the kunit.action parameter visible in sysfs.
>
> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> ---

Hello!

Great idea to expose this feature to modules. But just letting you
know this patch didn't apply cleanly for me onto the current
kselftest/kunit branch. So this may need rebasing.

>  include/kunit/test.h |  1 +
>  lib/kunit/executor.c | 19 +++++++++++++------
>  lib/kunit/test.c     | 30 +++++++++++++++++++++++++++++-
>  3 files changed, 43 insertions(+), 7 deletions(-)
>
> diff --git a/include/kunit/test.h b/include/kunit/test.h
> index 23120d50499ef..6d693f21a4833 100644
> --- a/include/kunit/test.h
> +++ b/include/kunit/test.h
> @@ -237,6 +237,7 @@ static inline void kunit_set_failure(struct kunit *test)
>  }
>
>  bool kunit_enabled(void);
> +const char *kunit_action(void);
>
>  void kunit_init_test(struct kunit *test, const char *name, char *log);
>
> diff --git a/lib/kunit/executor.c b/lib/kunit/executor.c
> index 74982b83707ca..d1c0616569dfd 100644
> --- a/lib/kunit/executor.c
> +++ b/lib/kunit/executor.c
> @@ -12,19 +12,26 @@
>  extern struct kunit_suite * const __kunit_suites_start[];
>  extern struct kunit_suite * const __kunit_suites_end[];
>
> +static char *action_param;
> +
> +module_param_named(action, action_param, charp, 0400);
> +MODULE_PARM_DESC(action,
> +                "Changes KUnit executor behavior, valid values are:\n"
> +                "<none>: run the tests like normal\n"
> +                "'list' to list test names instead of running them.\n");
> +
> +const char *kunit_action(void)
> +{
> +       return action_param;
> +}
> +
>  #if IS_BUILTIN(CONFIG_KUNIT)
>
>  static char *filter_glob_param;
> -static char *action_param;
>
>  module_param_named(filter_glob, filter_glob_param, charp, 0);
>  MODULE_PARM_DESC(filter_glob,
>                 "Filter which KUnit test suites/tests run at boot-time, e.g. list* or list*.*del_test");
> -module_param_named(action, action_param, charp, 0);
> -MODULE_PARM_DESC(action,
> -                "Changes KUnit executor behavior, valid values are:\n"
> -                "<none>: run the tests like normal\n"
> -                "'list' to list test names instead of running them.\n");
>
>  /* glob_match() needs NULL terminated strings, so we need a copy of filter_glob_param. */
>  struct kunit_test_filter {
> diff --git a/lib/kunit/test.c b/lib/kunit/test.c
> index a29ca1acc4d81..413d9fd364a8d 100644
> --- a/lib/kunit/test.c
> +++ b/lib/kunit/test.c
> @@ -674,6 +674,27 @@ int kunit_run_tests(struct kunit_suite *suite)
>  }
>  EXPORT_SYMBOL_GPL(kunit_run_tests);
>
> +static void kunit_list_suite(struct kunit_suite *suite)
> +{
> +       struct kunit_case *test_case;
> +
> +       kunit_print_suite_start(suite);
> +
> +       kunit_suite_for_each_test_case(suite, test_case) {
> +               struct kunit test = { .param_value = NULL, .param_index = 0 };
> +
> +               kunit_init_test(&test, test_case->name, test_case->log);
> +
> +               kunit_print_ok_not_ok(&test, true, KUNIT_SKIPPED,
> +                                     kunit_test_case_num(suite, test_case),
> +                                     test_case->name, "list mode");
> +       }
> +
> +       kunit_print_ok_not_ok((void *)suite, false, KUNIT_SKIPPED,
> +                             kunit_suite_counter++,
> +                             suite->name, "list mode");
> +}
> +

I have some reservations about using a different format to the current
format output when using the action_param=list option. Is it possible
to export and use the kunit_exec_list_tests() method instead? This
would allow for there to be only one method to control the format for
this option.

Also just a note that the new attributes patches introduce the
action_param.list_attr option, which would then need to be accounted
for here and maybe change some of this formatting.

Thanks!
Rae

>  static void kunit_init_suite(struct kunit_suite *suite)
>  {
>         kunit_debugfs_create_suite(suite);
> @@ -688,6 +709,7 @@ bool kunit_enabled(void)
>
>  int __kunit_test_suites_init(struct kunit_suite * const * const suites, int num_suites)
>  {
> +       const char *action = kunit_action();
>         unsigned int i;
>
>         if (!kunit_enabled() && num_suites > 0) {
> @@ -699,7 +721,13 @@ int __kunit_test_suites_init(struct kunit_suite * const * const suites, int num_
>
>         for (i = 0; i < num_suites; i++) {
>                 kunit_init_suite(suites[i]);
> -               kunit_run_tests(suites[i]);
> +
> +               if (!action)
> +                       kunit_run_tests(suites[i]);
> +               else if (!strcmp(action, "list"))
> +                       kunit_list_suite(suites[i]);
> +               else
> +                       pr_err("kunit: unknown action '%s'\n", action);
>         }
>
>         static_branch_dec(&kunit_running);
> --
> 2.41.0
>
> --
> You received this message because you are subscribed to the Google Groups "KUnit Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kunit-dev+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kunit-dev/20230731141021.2854827-7-janusz.krzysztofik%40linux.intel.com.

[PATCH v3 3/3] kunit: Allow kunit test modules to use test filtering

[Janusz Krzysztofik]

External tools, e.g., Intel GPU tools (IGT), support execution of
individual selftests provided by kernel modules.  That could be also
applicable to kunit test modules if they provided test filtering.  But
test filtering is now possible only when kunit code is built into the
kernel.  Moreover, a filter can be specified only at boot time, then
reboot is required each time a different filter is needed.

Build the test filtering code also when kunit is configured as a module,
expose test filtering functions to other kunit source files, and use them
in kunit module notifier callback functions.  Userspace can then reload
the kunit module with a value of the filter_glob parameter tuned to a
specific kunit test module every time it wants to limit the scope of tests
executed on that module load.  Make the kunit.filter_glob parameter
visible in sysfs for user convenience.

v3: Fix CONFIG_GLOB, required by filtering fuctions, not selected when
    building as a module.
v2: Fix new name of a structure moved to kunit namespace not updated
    across all uses.

Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
---
 include/kunit/test.h | 13 +++++++++++++
 lib/kunit/Kconfig    |  2 +-
 lib/kunit/executor.c | 42 ++++++++++++++++++++++--------------------
 lib/kunit/test.c     | 22 ++++++++++++++++++++++
 4 files changed, 58 insertions(+), 21 deletions(-)

diff --git a/include/kunit/test.h b/include/kunit/test.h
index 6d693f21a4833..14ff12e72252a 100644
--- a/include/kunit/test.h
+++ b/include/kunit/test.h
@@ -190,6 +190,12 @@ struct kunit_suite {
 	int suite_init_err;
 };
 
+/* Stores an array of suites, end points one past the end */
+struct kunit_suite_set {
+	struct kunit_suite * const *start;
+	struct kunit_suite * const *end;
+};
+
 /**
  * struct kunit - represents a running instance of a test.
  *
@@ -238,6 +244,7 @@ static inline void kunit_set_failure(struct kunit *test)
 
 bool kunit_enabled(void);
 const char *kunit_action(void);
+const char *kunit_filter_glob(void);
 
 void kunit_init_test(struct kunit *test, const char *name, char *log);
 
@@ -248,6 +255,12 @@ size_t kunit_suite_num_test_cases(struct kunit_suite *suite);
 unsigned int kunit_test_case_num(struct kunit_suite *suite,
 				 struct kunit_case *test_case);
 
+struct kunit_suite_set
+kunit_filter_suites(const struct kunit_suite_set *suite_set,
+		    const char *filter_glob,
+		    int *err);
+void kunit_free_suite_set(struct kunit_suite_set suite_set);
+
 int __kunit_test_suites_init(struct kunit_suite * const * const suites, int num_suites);
 
 void __kunit_test_suites_exit(struct kunit_suite **suites, int num_suites);
diff --git a/lib/kunit/Kconfig b/lib/kunit/Kconfig
index 626719b95badd..68a6daec0aef1 100644
--- a/lib/kunit/Kconfig
+++ b/lib/kunit/Kconfig
@@ -4,7 +4,7 @@
 
 menuconfig KUNIT
 	tristate "KUnit - Enable support for unit tests"
-	select GLOB if KUNIT=y
+	select GLOB
 	help
 	  Enables support for kernel unit tests (KUnit), a lightweight unit
 	  testing and mocking framework for the Linux kernel. These tests are
diff --git a/lib/kunit/executor.c b/lib/kunit/executor.c
index d1c0616569dfd..49fe40cc8f1af 100644
--- a/lib/kunit/executor.c
+++ b/lib/kunit/executor.c
@@ -25,14 +25,17 @@ const char *kunit_action(void)
 	return action_param;
 }
 
-#if IS_BUILTIN(CONFIG_KUNIT)
-
 static char *filter_glob_param;
 
-module_param_named(filter_glob, filter_glob_param, charp, 0);
+module_param_named(filter_glob, filter_glob_param, charp, 0400);
 MODULE_PARM_DESC(filter_glob,
 		"Filter which KUnit test suites/tests run at boot-time, e.g. list* or list*.*del_test");
 
+const char *kunit_filter_glob(void)
+{
+	return filter_glob_param;
+}
+
 /* glob_match() needs NULL terminated strings, so we need a copy of filter_glob_param. */
 struct kunit_test_filter {
 	char *suite_glob;
@@ -96,16 +99,7 @@ kunit_filter_tests(const struct kunit_suite *const suite, const char *test_glob)
 	return copy;
 }
 
-static char *kunit_shutdown;
-core_param(kunit_shutdown, kunit_shutdown, charp, 0644);
-
-/* Stores an array of suites, end points one past the end */
-struct suite_set {
-	struct kunit_suite * const *start;
-	struct kunit_suite * const *end;
-};
-
-static void kunit_free_suite_set(struct suite_set suite_set)
+void kunit_free_suite_set(struct kunit_suite_set suite_set)
 {
 	struct kunit_suite * const *suites;
 
@@ -114,13 +108,14 @@ static void kunit_free_suite_set(struct suite_set suite_set)
 	kfree(suite_set.start);
 }
 
-static struct suite_set kunit_filter_suites(const struct suite_set *suite_set,
-					    const char *filter_glob,
-					    int *err)
+struct kunit_suite_set
+kunit_filter_suites(const struct kunit_suite_set *suite_set,
+		    const char *filter_glob,
+		    int *err)
 {
 	int i;
 	struct kunit_suite **copy, *filtered_suite;
-	struct suite_set filtered;
+	struct kunit_suite_set filtered;
 	struct kunit_test_filter filter;
 
 	const size_t max = suite_set->end - suite_set->start;
@@ -155,6 +150,11 @@ static struct suite_set kunit_filter_suites(const struct suite_set *suite_set,
 	return filtered;
 }
 
+#if IS_BUILTIN(CONFIG_KUNIT)
+
+static char *kunit_shutdown;
+core_param(kunit_shutdown, kunit_shutdown, charp, 0644);
+
 static void kunit_handle_shutdown(void)
 {
 	if (!kunit_shutdown)
@@ -169,7 +169,7 @@ static void kunit_handle_shutdown(void)
 
 }
 
-static void kunit_exec_run_tests(struct suite_set *suite_set)
+static void kunit_exec_run_tests(struct kunit_suite_set *suite_set)
 {
 	size_t num_suites = suite_set->end - suite_set->start;
 
@@ -179,7 +179,7 @@ static void kunit_exec_run_tests(struct suite_set *suite_set)
 	__kunit_test_suites_init(suite_set->start, num_suites);
 }
 
-static void kunit_exec_list_tests(struct suite_set *suite_set)
+static void kunit_exec_list_tests(struct kunit_suite_set *suite_set)
 {
 	struct kunit_suite * const *suites;
 	struct kunit_case *test_case;
@@ -195,7 +195,9 @@ static void kunit_exec_list_tests(struct suite_set *suite_set)
 
 int kunit_run_all_tests(void)
 {
-	struct suite_set suite_set = {__kunit_suites_start, __kunit_suites_end};
+	struct kunit_suite_set suite_set = {
+		__kunit_suites_start, __kunit_suites_end,
+	};
 	int err = 0;
 	if (!kunit_enabled()) {
 		pr_info("kunit: disabled\n");
diff --git a/lib/kunit/test.c b/lib/kunit/test.c
index 413d9fd364a8d..bfc2f65bd1dae 100644
--- a/lib/kunit/test.c
+++ b/lib/kunit/test.c
@@ -757,6 +757,22 @@ EXPORT_SYMBOL_GPL(__kunit_test_suites_exit);
 #ifdef CONFIG_MODULES
 static void kunit_module_init(struct module *mod)
 {
+	struct kunit_suite_set suite_set = {
+		mod->kunit_suites, mod->kunit_suites + mod->num_kunit_suites,
+	};
+	int err = 0;
+
+	suite_set = kunit_filter_suites(&suite_set,
+					kunit_filter_glob() ?: "*.*", &err);
+	if (err) {
+		pr_err("kunit module: error filtering suites: %d\n",
+		       err);
+		kfree(suite_set.start);
+		suite_set.start = NULL;
+	}
+	mod->kunit_suites = (struct kunit_suite **)suite_set.start;
+	mod->num_kunit_suites = suite_set.end - suite_set.start;
+
 	if (mod->num_kunit_suites > 0) {
 		pr_info("KTAP version 1\n");
 		pr_info("1..%d\n", mod->num_kunit_suites);
@@ -767,7 +783,13 @@ static void kunit_module_init(struct module *mod)
 
 static void kunit_module_exit(struct module *mod)
 {
+	struct kunit_suite_set suite_set = {
+		mod->kunit_suites, mod->kunit_suites + mod->num_kunit_suites,
+	};
+
 	__kunit_test_suites_exit(mod->kunit_suites, mod->num_kunit_suites);
+	if (suite_set.start)
+		kunit_free_suite_set(suite_set);
 }
 
 static int kunit_module_notify(struct notifier_block *nb, unsigned long val,
-- 
2.41.0