linux/include/kunit, branch v6.3

kunit: Expose 'static stub' API to redirect functions

2023-02-08T21:28:17Z

Add a simple way of redirecting calls to functions by including a special prologue in the "real" function which checks to see if the replacement function should be called (and, if so, calls it). To redirect calls to a function, make the first (non-declaration) line of the function: KUNIT_STATIC_STUB_REDIRECT(function_name, [function arguments]); (This will compile away to nothing if KUnit is not enabled, otherwise it will check if a redirection is active, call the replacement function, and return. This check is protected by a static branch, so has very little overhead when there are no KUnit tests running.) Calls to the real function can be redirected to a replacement using: kunit_activate_static_stub(test, real_fn, replacement_fn); The redirection will only affect calls made from within the kthread of the current test, and will be automatically disabled when the test completes. It can also be manually disabled with kunit_deactivate_static_stub(). The 'example' KUnit test suite has a more complete example. Co-developed-by: Daniel Latypov Signed-off-by: Daniel Latypov Signed-off-by: David Gow Reviewed-by: Brendan Higgins Signed-off-by: Shuah Khan

kunit: Add "hooks" to call into KUnit when it's built as a module

2023-02-08T21:26:25Z

KUnit has several macros and functions intended for use from non-test code. These hooks, currently the kunit_get_current_test() and kunit_fail_current_test() macros, didn't work when CONFIG_KUNIT=m. In order to support this case, the required functions and static data need to be available unconditionally, even when KUnit itself is not built-in. The new 'hooks.c' file is therefore always included, and has both the static key required for kunit_get_current_test(), and a table of function pointers in struct kunit_hooks_table. This is filled in with the real implementations by kunit_install_hooks(), which is kept in hooks-impl.h and called when the kunit module is loaded. This can be extended for future features which require similar "hook" behaviour, such as static stubs, by simply adding new entries to the struct, and the appropriate code to set them. Fixed white-space errors during commit: Shuah Khan Resolved merge conflicts with: db105c37a4d6 ("kunit: Export kunit_running()") This patch supersedes the above. Shuah Khan Signed-off-by: David Gow Reviewed-by: Rae Moar Reviewed-by: Brendan Higgins Signed-off-by: Shuah Khan

kunit: fix kunit_test_init_section_suites(...)

2023-01-31T16:10:38Z

Looks like kunit_test_init_section_suites(...) was messed up in a merge conflict. This fixes it. kunit_test_init_section_suites(...) was not updated to avoid the extra level of indirection when .kunit_test_suites was flattened. Given no-one was actively using it, this went unnoticed for a long period of time. Fixes: e5857d396f35 ("kunit: flatten kunit_suite*** to kunit_suite** in .kunit_test_suites") Signed-off-by: Brendan Higgins Signed-off-by: David Gow Tested-by: Martin Fernandez Signed-off-by: Shuah Khan

kunit: fix bug in KUNIT_EXPECT_MEMEQ

2023-01-30T21:46:46Z

In KUNIT_EXPECT_MEMEQ and KUNIT_EXPECT_MEMNEQ, add check if one of the inputs is NULL and fail if this is the case. Currently, the kernel crashes if one of the inputs is NULL. Instead, fail the test and add an appropriate error message. Fixes: b8a926bea8b1 ("kunit: Introduce KUNIT_EXPECT_MEMEQ and KUNIT_EXPECT_MEMNEQ macros") This was found by the kernel test robot: https://lore.kernel.org/all/202212191448.D6EDPdOh-lkp@intel.com/ Reported-by: kernel test robot Signed-off-by: Rae Moar Reviewed-by: David Gow Signed-off-by: Shuah Khan

kunit: add macro to allow conditionally exposing static symbols to tests

2022-12-12T21:13:48Z

Create two macros: VISIBLE_IF_KUNIT - A macro that sets symbols to be static if CONFIG_KUNIT is not enabled. Otherwise if CONFIG_KUNIT is enabled there is no change to the symbol definition. EXPORT_SYMBOL_IF_KUNIT(symbol) - Exports symbol into EXPORTED_FOR_KUNIT_TESTING namespace only if CONFIG_KUNIT is enabled. Must use MODULE_IMPORT_NS(EXPORTED_FOR_KUNIT_TESTING) in test file in order to use symbols. Signed-off-by: Rae Moar Reviewed-by: John Johansen Reviewed-by: David Gow Signed-off-by: Shuah Khan

kunit: Use the static key when retrieving the current test

2022-12-12T21:13:47Z

In order to detect if a KUnit test is running, and to access its context, the 'kunit_test' member of the current task_struct is used. Usually, this is accessed directly or via the kunit_fail_current_task() function. In order to speed up the case where no test is running, add a wrapper, kunit_get_current_test(), which uses the static key to fail early. Equally, Speed up kunit_fail_current_test() by using the static key. This should make it convenient for code to call this unconditionally in fakes or error paths, without worrying that this will slow the code down significantly. If CONFIG_KUNIT=n (or m), this compiles away to nothing. If CONFIG_KUNIT=y, it will compile down to a NOP (on most architectures) if no KUnit test is currently running. Note that kunit_get_current_test() does not work if KUnit is built as a module. This mirrors the existing restriction on kunit_fail_current_test(). Note that the definition of kunit_fail_current_test() still wraps an empty, inline function if KUnit is not built-in. This is to ensure that the printf format string __attribute__ will still work. Also update the documentation to suggest users use the new kunit_get_current_test() function, update the example, and to describe the behaviour when KUnit is disabled better. Cc: Jonathan Corbet Cc: Sadiya Kazi Signed-off-by: David Gow Reviewed-by: Daniel Latypov Signed-off-by: Shuah Khan

kunit: Provide a static key to check if KUnit is actively running tests

2022-12-12T21:13:47Z

KUnit does a few expensive things when enabled. This hasn't been a problem because KUnit was only enabled on test kernels, but with a few people enabling (but not _using_) KUnit on production systems, we need a runtime way of handling this. Provide a 'kunit_running' static key (defaulting to false), which allows us to hide any KUnit code behind a static branch. This should reduce the performance impact (on other code) of having KUnit enabled to a single NOP when no tests are running. Note that, while it looks unintuitive, tests always run entirely within __kunit_test_suites_init(), so it's safe to decrement the static key at the end of this function, rather than in __kunit_test_suites_exit(), which is only there to clean up results in debugfs. Signed-off-by: David Gow Reviewed-by: Daniel Latypov Signed-off-by: Shuah Khan

kunit: remove KUNIT_INIT_MEM_ASSERTION macro

2022-12-12T21:13:47Z

Commit 870f63b7cd78 ("kunit: eliminate KUNIT_INIT_*_ASSERT_STRUCT macros") removed all the other macros of this type. But it raced with commit b8a926bea8b1 ("kunit: Introduce KUNIT_EXPECT_MEMEQ and KUNIT_EXPECT_MEMNEQ macros"), which added another instance. Remove KUNIT_INIT_MEM_ASSERTION and just use the generic KUNIT_INIT_ASSERT macro instead. Rename the `size` arg to avoid conflicts by appending a "_" (like we did in the previous commit). Signed-off-by: Daniel Latypov Reviewed-by: David Gow Signed-off-by: Shuah Khan

kunit: eliminate KUNIT_INIT_*_ASSERT_STRUCT macros

2022-12-12T21:13:47Z

These macros exist because passing an initializer list to other macros is hard. The goal of these macros is to generate a line like struct $ASSERT_TYPE __assertion = $APPROPRIATE_INITIALIZER; e.g. struct kunit_unary_assertion __assertion = { .condition = "foo()", .expected_true = true }; But the challenge is you can't pass `{.condition=..., .expect_true=...}` as a macro argument, since the comma means you're actually passing two arguments, `{.condition=...` and `.expect_true=....}`. So we'd made custom macros for each different initializer-list shape. But we can work around this with the following generic macro #define KUNIT_INIT_ASSERT(initializers...) { initializers } Note: this has the downside that we have to rename some macros arguments to not conflict with the struct field names (e.g. `expected_true`). It's a bit gross, but probably worth reducing the # of macros. Signed-off-by: Daniel Latypov Reviewed-by: David Gow Signed-off-by: Shuah Khan

kunit: Introduce KUNIT_EXPECT_MEMEQ and KUNIT_EXPECT_MEMNEQ macros

2022-10-27T08:39:47Z

Currently, in order to compare memory blocks in KUnit, the KUNIT_EXPECT_EQ or KUNIT_EXPECT_FALSE macros are used in conjunction with the memcmp function, such as: KUNIT_EXPECT_EQ(test, memcmp(foo, bar, size), 0); Although this usage produces correct results for the test cases, when the expectation fails, the error message is not very helpful, indicating only the return of the memcmp function. Therefore, create a new set of macros KUNIT_EXPECT_MEMEQ and KUNIT_EXPECT_MEMNEQ that compare memory blocks until a specified size. In case of expectation failure, those macros print the hex dump of the memory blocks, making it easier to debug test failures for memory blocks. That said, the expectation KUNIT_EXPECT_EQ(test, memcmp(foo, bar, size), 0); would translate to the expectation KUNIT_EXPECT_MEMEQ(test, foo, bar, size); Signed-off-by: Maíra Canal Reviewed-by: Daniel Latypov Reviewed-by: Muhammad Usama Anjum Reviewed-by: David Gow Signed-off-by: Shuah Khan