[0/5] Rework KUnit test execution in modules

Message

David Gow June 18, 2022, 9:03 a.m. UTC

This patch series makes two changes to how KUnit test suites are stored
and executed:
- The .kunit_test_suites section is now used for tests in modules (in
  lieu of a module_init funciton), as well as for built-in tests. The
  module loader will now trigger test execution. This frees up the
  module_init function for other uses.
- Instead of storing an array of arrays of suites, have the
  kunit_test_suite() and kunit_test_suites() macros append to one global
  (or per-module) list of test suites. This removes a needless layer of
  indirection.

The upshot of this is that it should now be possible to use the
kunit_test_suite() and kunit_test_suites() macros to register test
suites even from within modules which otherwise had module_init
functions. This was proving to be quite a common issue, resulting in
several modules calling into KUnit's private suite execution functions
to run their tests (often introducing incompatibilities with the KUnit
tooling).

This series also fixes the thunderbolt, nitro_enclaves, and
sdhci-of-aspeed tests to use kunit_test_suite() now that it works.

Huge thanks to Jeremy Kerr, who designed and implemented the module
loader changes, and to Daniel Latypov for pushing the simplification of
the nested arrays in .kunit_test_suites.

I've tested this series both with builtin tests, and with modules on
x86_64, but there's always the possibility that there's something subtle
and nasty on another architecture, so please test!

Cheers,
-- David

Daniel Latypov (1):
  kunit: flatten kunit_suite*** to kunit_suite** in .kunit_test_suites

David Gow (3):
  thunderbolt: test: Use kunit_test_suite() macro
  nitro_enclaves: test: Use kunit_test_suite() macro
  mmc: sdhci-of-aspeed: test: Use kunit_test_suite() macro

Jeremy Kerr (1):
  kunit: unify module and builtin suite definitions

 drivers/mmc/host/Kconfig                      |   5 +-
 drivers/mmc/host/sdhci-of-aspeed-test.c       |   8 +-
 drivers/mmc/host/sdhci-of-aspeed.c            |  27 ----
 drivers/thunderbolt/Kconfig                   |   5 +-
 drivers/thunderbolt/domain.c                  |   3 -
 drivers/thunderbolt/tb.h                      |   8 -
 drivers/thunderbolt/test.c                    |  12 +-
 drivers/virt/nitro_enclaves/Kconfig           |   5 +-
 drivers/virt/nitro_enclaves/ne_misc_dev.c     |  27 ----
 .../virt/nitro_enclaves/ne_misc_dev_test.c    |   5 +-
 include/kunit/test.h                          |  60 ++------
 include/linux/module.h                        |   5 +
 kernel/module/main.c                          |   6 +
 lib/kunit/executor.c                          | 117 ++++-----------
 lib/kunit/executor_test.c                     | 139 +++++-------------
 lib/kunit/test.c                              |  54 ++++++-
 16 files changed, 152 insertions(+), 334 deletions(-)

Comments

Maíra Canal June 18, 2022, 5:11 p.m. UTC | #1

On 6/18/22 06:03, David Gow wrote:
> This patch series makes two changes to how KUnit test suites are stored
> and executed:
> - The .kunit_test_suites section is now used for tests in modules (in
>   lieu of a module_init funciton), as well as for built-in tests. The
>   module loader will now trigger test execution. This frees up the
>   module_init function for other uses.
> - Instead of storing an array of arrays of suites, have the
>   kunit_test_suite() and kunit_test_suites() macros append to one global
>   (or per-module) list of test suites. This removes a needless layer of
>   indirection.
> 
> The upshot of this is that it should now be possible to use the
> kunit_test_suite() and kunit_test_suites() macros to register test
> suites even from within modules which otherwise had module_init
> functions. This was proving to be quite a common issue, resulting in
> several modules calling into KUnit's private suite execution functions
> to run their tests (often introducing incompatibilities with the KUnit
> tooling).
> 
> This series also fixes the thunderbolt, nitro_enclaves, and
> sdhci-of-aspeed tests to use kunit_test_suite() now that it works.
> 
> Huge thanks to Jeremy Kerr, who designed and implemented the module
> loader changes, and to Daniel Latypov for pushing the simplification of
> the nested arrays in .kunit_test_suites.
> 
> I've tested this series both with builtin tests, and with modules on
> x86_64, but there's always the possibility that there's something subtle
> and nasty on another architecture, so please test!
> 
> Cheers,
> -- David
> 

I've tested the modules on x86_64 machines, and everything looks fine.
Also, I applied the AMDGPU KUnit tests [1] on top of these patches,
tried out compiling as a module, and it runs pretty well!

Great to see this feature on KUnit!

Tested-by: Maíra Canal <[e-mail]>

[1] https://lore.kernel.org/dri-devel/20220608010709.272962-1
[e-mail]/

Best Regards,
- Maíra Canal

Christophe Leroy June 18, 2022, 5:41 p.m. UTC | #2

Le 18/06/2022 à 11:03, David Gow a écrit :
> [Vous ne recevez pas souvent de courriers de [e-mail]. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
> 
> This patch series makes two changes to how KUnit test suites are stored
> and executed:
> - The .kunit_test_suites section is now used for tests in modules (in
>    lieu of a module_init funciton), as well as for built-in tests. The
>    module loader will now trigger test execution. This frees up the
>    module_init function for other uses.
> - Instead of storing an array of arrays of suites, have the
>    kunit_test_suite() and kunit_test_suites() macros append to one global
>    (or per-module) list of test suites. This removes a needless layer of
>    indirection.
> 
> The upshot of this is that it should now be possible to use the
> kunit_test_suite() and kunit_test_suites() macros to register test
> suites even from within modules which otherwise had module_init
> functions. This was proving to be quite a common issue, resulting in
> several modules calling into KUnit's private suite execution functions
> to run their tests (often introducing incompatibilities with the KUnit
> tooling).
> 
> This series also fixes the thunderbolt, nitro_enclaves, and
> sdhci-of-aspeed tests to use kunit_test_suite() now that it works.
> 
> Huge thanks to Jeremy Kerr, who designed and implemented the module
> loader changes, and to Daniel Latypov for pushing the simplification of
> the nested arrays in .kunit_test_suites.
> 
> I've tested this series both with builtin tests, and with modules on
> x86_64, but there's always the possibility that there's something subtle
> and nasty on another architecture, so please test!

Build failure on powerpc architecture with ppc64_defconfig + 
CONFIG_KUNIT_TEST=m

   CC [M]  lib/kunit/test.o
lib/kunit/test.c: In function 'kunit_module_init':
lib/kunit/test.c:616:37: error: 'struct module' has no member named 
'kunit_suites'
   616 |         __kunit_test_suites_init(mod->kunit_suites, 
mod->num_kunit_suites);
       |                                     ^~
lib/kunit/test.c:616:56: error: 'struct module' has no member named 
'num_kunit_suites'
   616 |         __kunit_test_suites_init(mod->kunit_suites, 
mod->num_kunit_suites);
       |                                                        ^~
lib/kunit/test.c: In function 'kunit_module_exit':
lib/kunit/test.c:621:37: error: 'struct module' has no member named 
'kunit_suites'
   621 |         __kunit_test_suites_exit(mod->kunit_suites, 
mod->num_kunit_suites);
       |                                     ^~
lib/kunit/test.c:621:56: error: 'struct module' has no member named 
'num_kunit_suites'
   621 |         __kunit_test_suites_exit(mod->kunit_suites, 
mod->num_kunit_suites);
       |                                                        ^~


Christophe