[0/2] kunit: add boot time parameter to enable KUnit

There are some use cases where the kernel binary is desired to be the same
for both production and testing. This poses a problem for users of KUnit
as built-in tests will automatically run at startup and test modules
can still be loaded leaving the kernel in an unsafe state. There is a
"test" taint flag that gets set if a test runs but nothing to prevent
the execution.

This patch adds the kunit.enable module parameter that will need to be
set to true in addition to KUNIT being enabled for KUnit tests to run.
The default value is true giving backwards compatibility. However, for
the production+testing use case the new config option
KUNIT_ENABLE_DEFAULT_DISABLED can be enabled to default kunit.enable to
false requiring the tester to opt-in by passing kunit.enable=1 to
the kernel.

Joe Fradley (2):
  kunit: add kunit.enable to enable/disable KUnit test
  kunit: no longer call module_info(test, "Y") for kunit modules

 .../admin-guide/kernel-parameters.txt         |  6 ++++++
 include/kunit/test.h                          |  1 -
 lib/kunit/Kconfig                             |  8 ++++++++
 lib/kunit/test.c                              | 20 +++++++++++++++++++
 4 files changed, 34 insertions(+), 1 deletion(-)

On Thu, Aug 18, 2022 at 12:49 AM Joe Fradley <joefradley@google.com> wrote:
>
> Because KUnit test execution is not a guarantee with the kunit.enable
> parameter we want to be careful to only taint the kernel only if an
> actual test runs. Calling module_info(test, "Y") for every KUnit module
> automatically causes the kernel to be tainted upon module load. Therefore,
> we're removing this call and relying on the KUnit framework to taint the
> kernel or not.
>
> Signed-off-by: Joe Fradley <joefradley@google.com>
> ---

Thanks!

This definitely fixes an assumption I'd had about KUnit-usage which
definitely doesn't hold: that all KUnit tests would be in their own
modules (or at least that those modules wouldn't need to be loaded on
otherwise production systems). Given this isn't the case for a number
of modules (thuderbolt, apparmor, probably soon amdgpu), it makles
sense to get rid of this and only taint the kernel when the test is
actually run, not just when it's loaded.

This could be considered a fix for c272612cb4a2 ("kunit: Taint the
kernel when KUnit tests are run"), as it'd already be possible to
load, e.g., thunderbolt, but prevent the tests from executing with a
filter glob which doesn't match any tests. That possibly shouldn't
taint the kernel.

Reviewed-by: David Gow <davidgow@google.com>
Fixes: c272612cb4a2 ("kunit: Taint the kernel when KUnit tests are run")

Cheers,
-- David

>  include/kunit/test.h | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/include/kunit/test.h b/include/kunit/test.h
> index c958855681cc..f23d3954aa17 100644
> --- a/include/kunit/test.h
> +++ b/include/kunit/test.h
> @@ -251,7 +251,6 @@ static inline int kunit_run_all_tests(void)
>  #endif /* IS_BUILTIN(CONFIG_KUNIT) */
>
>  #define __kunit_test_suites(unique_array, ...)                                \
> -       MODULE_INFO(test, "Y");                                                \
>         static struct kunit_suite *unique_array[]                              \
>         __aligned(sizeof(struct kunit_suite *))                                \
>         __used __section(".kunit_test_suites") = { __VA_ARGS__ }
> --
> 2.37.1.595.g718a3a8f04-goog
>

On Fri, Aug 19, 2022 at 1:34 AM David Gow <davidgow@google.com> wrote:
>
> On Thu, Aug 18, 2022 at 12:49 AM Joe Fradley <joefradley@google.com> wrote:
> >
> > Because KUnit test execution is not a guarantee with the kunit.enable
> > parameter we want to be careful to only taint the kernel only if an
> > actual test runs. Calling module_info(test, "Y") for every KUnit module
> > automatically causes the kernel to be tainted upon module load. Therefore,
> > we're removing this call and relying on the KUnit framework to taint the
> > kernel or not.
> >
> > Signed-off-by: Joe Fradley <joefradley@google.com>
> > ---
>
> Thanks!
>
> This definitely fixes an assumption I'd had about KUnit-usage which
> definitely doesn't hold: that all KUnit tests would be in their own
> modules (or at least that those modules wouldn't need to be loaded on
> otherwise production systems). Given this isn't the case for a number
> of modules (thuderbolt, apparmor, probably soon amdgpu), it makles
> sense to get rid of this and only taint the kernel when the test is
> actually run, not just when it's loaded.
>
> This could be considered a fix for c272612cb4a2 ("kunit: Taint the
> kernel when KUnit tests are run"), as it'd already be possible to
> load, e.g., thunderbolt, but prevent the tests from executing with a
> filter glob which doesn't match any tests. That possibly shouldn't
> taint the kernel.

Great, thank you for the review.

>
> Reviewed-by: David Gow <davidgow@google.com>
> Fixes: c272612cb4a2 ("kunit: Taint the kernel when KUnit tests are run")
>
> Cheers,
> -- David
>
> >  include/kunit/test.h | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/include/kunit/test.h b/include/kunit/test.h
> > index c958855681cc..f23d3954aa17 100644
> > --- a/include/kunit/test.h
> > +++ b/include/kunit/test.h
> > @@ -251,7 +251,6 @@ static inline int kunit_run_all_tests(void)
> >  #endif /* IS_BUILTIN(CONFIG_KUNIT) */
> >
> >  #define __kunit_test_suites(unique_array, ...)                                \
> > -       MODULE_INFO(test, "Y");                                                \
> >         static struct kunit_suite *unique_array[]                              \
> >         __aligned(sizeof(struct kunit_suite *))                                \
> >         __used __section(".kunit_test_suites") = { __VA_ARGS__ }
> > --
> > 2.37.1.595.g718a3a8f04-goog
> >

On Wed, Aug 17, 2022 at 12:49 PM 'Joe Fradley' via KUnit Development
<kunit-dev@googlegroups.com> wrote:
>
> Because KUnit test execution is not a guarantee with the kunit.enable
> parameter we want to be careful to only taint the kernel only if an
> actual test runs. Calling module_info(test, "Y") for every KUnit module
> automatically causes the kernel to be tainted upon module load. Therefore,
> we're removing this call and relying on the KUnit framework to taint the
> kernel or not.
>
> Signed-off-by: Joe Fradley <joefradley@google.com>

Reviewed-by: Brendan Higgins <brendanhiggins@google.com>