linux/include/kunit/test.h, branch v6.4

kunit: increase KUNIT_LOG_SIZE to 2048 bytes

2023-03-30T00:55:41Z

The s390 specific test_unwind kunit test has 39 parameterized tests. The results in debugfs are truncated since the full log doesn't fit into 1500 bytes. Therefore increase KUNIT_LOG_SIZE to 2048 bytes in a similar way like it was done recently with commit "kunit: fix bug in debugfs logs of parameterized tests". With that the whole test result is present. Reported-by: Alexander Egorenkov Signed-off-by: Heiko Carstens Reviewed-by: Rae Moar Reviewed-by: David Gow Signed-off-by: Shuah Khan

kunit: fix bug of extra newline characters in debugfs logs

2023-03-10T20:59:43Z

Fix bug of the extra newline characters in debugfs logs. When a line is added to debugfs with a newline character at the end, an extra line appears in the debugfs log. This is due to a discrepancy between how the lines are printed and how they are added to the logs. Remove this discrepancy by checking if a newline character is present before adding a newline character. This should closely match the printk behavior. Add kunit_log_newline_test to provide test coverage for this issue. (Also, move kunit_log_test above suite definition to remove the unnecessary declaration prior to the suite definition) As an example, say we add these two lines to the log: kunit_log(..., "KTAP version 1\n"); kunit_log(..., "1..1"); The debugfs log before this fix: KTAP version 1 1..1 The debugfs log after this fix: KTAP version 1 1..1 Signed-off-by: Rae Moar Reviewed-by: David Gow Signed-off-by: Shuah Khan

kunit: fix bug in debugfs logs of parameterized tests

2023-03-10T20:59:32Z

Fix bug in debugfs logs that causes individual parameterized results to not appear because the log is reinitialized (cleared) when each parameter is run. Ensure these results appear in the debugfs logs, increase log size to allow for the size of parameterized results. As a result, append lines to the log directly rather than using an intermediate variable that can cause stack size warnings due to the increased log size. Here is the debugfs log of ext4_inode_test which uses parameterized tests before the fix: KTAP version 1 # Subtest: ext4_inode_test 1..1 # Totals: pass:16 fail:0 skip:0 total:16 ok 1 ext4_inode_test As you can see, this log does not include any of the individual parametrized results. After (in combination with the next two fixes to remove extra empty line and ensure KTAP valid format): KTAP version 1 1..1 KTAP version 1 # Subtest: ext4_inode_test 1..1 KTAP version 1 # Subtest: inode_test_xtimestamp_decoding ok 1 1901-12-13 Lower bound of 32bit < 0 timestamp, no extra bits ... (the rest of the individual parameterized tests) ok 16 2446-05-10 Upper bound of 32bit >=0 timestamp. All extra # inode_test_xtimestamp_decoding: pass:16 fail:0 skip:0 total:16 ok 1 inode_test_xtimestamp_decoding # Totals: pass:16 fail:0 skip:0 total:16 ok 1 ext4_inode_test Signed-off-by: Rae Moar Reviewed-by: David Gow 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: 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

kunit: declare kunit_assert structs as const

2022-10-07T16:19:18Z

Everywhere we use the assert structs now takes them via const*, as of commit 7466886b400b ("kunit: take `kunit_assert` as `const`"). So now let's properly declare the structs as const as well. Signed-off-by: Daniel Latypov Reviewed-by: David Gow Reviewed-by: Miguel Ojeda Signed-off-by: Shuah Khan