2019-09-23 09:02:31 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
|
|
|
/*
|
|
|
|
* Base unit test (KUnit) API.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2019, Google LLC.
|
|
|
|
* Author: Brendan Higgins <brendanhiggins@google.com>
|
|
|
|
*/
|
|
|
|
|
2022-03-28 17:41:43 +00:00
|
|
|
#include <kunit/resource.h>
|
2019-09-23 09:02:31 +00:00
|
|
|
#include <kunit/test.h>
|
2021-03-11 15:23:13 +00:00
|
|
|
#include <kunit/test-bug.h>
|
2023-07-25 21:25:12 +00:00
|
|
|
#include <kunit/attributes.h>
|
2019-09-23 09:02:31 +00:00
|
|
|
#include <linux/kernel.h>
|
2022-07-09 03:19:57 +00:00
|
|
|
#include <linux/module.h>
|
2021-08-04 05:08:08 +00:00
|
|
|
#include <linux/moduleparam.h>
|
2022-07-01 08:47:43 +00:00
|
|
|
#include <linux/panic.h>
|
2019-09-23 09:02:39 +00:00
|
|
|
#include <linux/sched/debug.h>
|
2020-10-13 23:55:02 +00:00
|
|
|
#include <linux/sched.h>
|
2019-09-23 09:02:31 +00:00
|
|
|
|
2020-03-26 14:25:07 +00:00
|
|
|
#include "debugfs.h"
|
kunit: Add "hooks" to call into KUnit when it's built as a module
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 <skhan@linuxfoundation.org>
Resolved merge conflicts with:
db105c37a4d6 ("kunit: Export kunit_running()")
This patch supersedes the above.
Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: David Gow <davidgow@google.com>
Reviewed-by: Rae Moar <rmoar@google.com>
Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2023-01-28 07:10:07 +00:00
|
|
|
#include "hooks-impl.h"
|
2020-01-06 22:28:18 +00:00
|
|
|
#include "string-stream.h"
|
2020-01-06 22:28:19 +00:00
|
|
|
#include "try-catch-impl.h"
|
2020-01-06 22:28:18 +00:00
|
|
|
|
2021-03-11 15:23:13 +00:00
|
|
|
/*
|
kunit: Add "hooks" to call into KUnit when it's built as a module
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 <skhan@linuxfoundation.org>
Resolved merge conflicts with:
db105c37a4d6 ("kunit: Export kunit_running()")
This patch supersedes the above.
Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: David Gow <davidgow@google.com>
Reviewed-by: Rae Moar <rmoar@google.com>
Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2023-01-28 07:10:07 +00:00
|
|
|
* Hook to fail the current test and print an error message to the log.
|
2021-03-11 15:23:13 +00:00
|
|
|
*/
|
2023-02-04 04:04:53 +00:00
|
|
|
void __printf(3, 4) __kunit_fail_current_test_impl(const char *file, int line, const char *fmt, ...)
|
2021-03-11 15:23:13 +00:00
|
|
|
{
|
|
|
|
va_list args;
|
|
|
|
int len;
|
|
|
|
char *buffer;
|
|
|
|
|
|
|
|
if (!current->kunit_test)
|
|
|
|
return;
|
|
|
|
|
|
|
|
kunit_set_failure(current->kunit_test);
|
|
|
|
|
|
|
|
/* kunit_err() only accepts literals, so evaluate the args first. */
|
|
|
|
va_start(args, fmt);
|
|
|
|
len = vsnprintf(NULL, 0, fmt, args) + 1;
|
|
|
|
va_end(args);
|
|
|
|
|
|
|
|
buffer = kunit_kmalloc(current->kunit_test, len, GFP_KERNEL);
|
|
|
|
if (!buffer)
|
|
|
|
return;
|
|
|
|
|
|
|
|
va_start(args, fmt);
|
|
|
|
vsnprintf(buffer, len, fmt, args);
|
|
|
|
va_end(args);
|
|
|
|
|
|
|
|
kunit_err(current->kunit_test, "%s:%d: %s", file, line, buffer);
|
|
|
|
kunit_kfree(current->kunit_test, buffer);
|
|
|
|
}
|
|
|
|
|
2022-08-23 14:24:54 +00:00
|
|
|
/*
|
|
|
|
* Enable KUnit tests to run.
|
|
|
|
*/
|
|
|
|
#ifdef CONFIG_KUNIT_DEFAULT_ENABLED
|
|
|
|
static bool enable_param = true;
|
|
|
|
#else
|
|
|
|
static bool enable_param;
|
|
|
|
#endif
|
|
|
|
module_param_named(enable, enable_param, bool, 0);
|
|
|
|
MODULE_PARM_DESC(enable, "Enable KUnit tests");
|
|
|
|
|
2021-08-04 05:08:08 +00:00
|
|
|
/*
|
|
|
|
* KUnit statistic mode:
|
|
|
|
* 0 - disabled
|
|
|
|
* 1 - only when there is more than one subtest
|
|
|
|
* 2 - enabled
|
|
|
|
*/
|
|
|
|
static int kunit_stats_enabled = 1;
|
|
|
|
module_param_named(stats_enabled, kunit_stats_enabled, int, 0644);
|
|
|
|
MODULE_PARM_DESC(stats_enabled,
|
|
|
|
"Print test stats: never (0), only for multiple subtests (1), or always (2)");
|
|
|
|
|
|
|
|
struct kunit_result_stats {
|
|
|
|
unsigned long passed;
|
|
|
|
unsigned long skipped;
|
|
|
|
unsigned long failed;
|
|
|
|
unsigned long total;
|
|
|
|
};
|
|
|
|
|
|
|
|
static bool kunit_should_print_stats(struct kunit_result_stats stats)
|
|
|
|
{
|
|
|
|
if (kunit_stats_enabled == 0)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (kunit_stats_enabled == 2)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return (stats.total > 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void kunit_print_test_stats(struct kunit *test,
|
|
|
|
struct kunit_result_stats stats)
|
|
|
|
{
|
|
|
|
if (!kunit_should_print_stats(stats))
|
|
|
|
return;
|
|
|
|
|
|
|
|
kunit_log(KERN_INFO, test,
|
|
|
|
KUNIT_SUBTEST_INDENT
|
|
|
|
"# %s: pass:%lu fail:%lu skip:%lu total:%lu",
|
|
|
|
test->name,
|
|
|
|
stats.passed,
|
|
|
|
stats.failed,
|
|
|
|
stats.skipped,
|
|
|
|
stats.total);
|
|
|
|
}
|
|
|
|
|
2023-08-28 10:41:10 +00:00
|
|
|
/* Append formatted message to log. */
|
|
|
|
void kunit_log_append(struct string_stream *log, const char *fmt, ...)
|
2020-03-26 14:25:07 +00:00
|
|
|
{
|
|
|
|
va_list args;
|
|
|
|
|
|
|
|
if (!log)
|
|
|
|
return;
|
|
|
|
|
|
|
|
va_start(args, fmt);
|
2023-08-28 10:41:10 +00:00
|
|
|
string_stream_vadd(log, fmt, args);
|
2023-03-08 20:39:50 +00:00
|
|
|
va_end(args);
|
2020-03-26 14:25:07 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(kunit_log_append);
|
|
|
|
|
|
|
|
size_t kunit_suite_num_test_cases(struct kunit_suite *suite)
|
2019-09-23 09:02:31 +00:00
|
|
|
{
|
|
|
|
struct kunit_case *test_case;
|
|
|
|
size_t len = 0;
|
|
|
|
|
2020-03-26 14:25:07 +00:00
|
|
|
kunit_suite_for_each_test_case(suite, test_case)
|
2019-09-23 09:02:31 +00:00
|
|
|
len++;
|
|
|
|
|
|
|
|
return len;
|
|
|
|
}
|
2020-03-26 14:25:07 +00:00
|
|
|
EXPORT_SYMBOL_GPL(kunit_suite_num_test_cases);
|
2019-09-23 09:02:31 +00:00
|
|
|
|
2023-07-25 21:25:12 +00:00
|
|
|
/* Currently supported test levels */
|
|
|
|
enum {
|
|
|
|
KUNIT_LEVEL_SUITE = 0,
|
|
|
|
KUNIT_LEVEL_CASE,
|
|
|
|
KUNIT_LEVEL_CASE_PARAM,
|
|
|
|
};
|
|
|
|
|
2022-04-29 18:12:56 +00:00
|
|
|
static void kunit_print_suite_start(struct kunit_suite *suite)
|
2019-09-23 09:02:31 +00:00
|
|
|
{
|
2023-03-08 20:39:51 +00:00
|
|
|
/*
|
|
|
|
* We do not log the test suite header as doing so would
|
|
|
|
* mean debugfs display would consist of the test suite
|
|
|
|
* header prior to individual test results.
|
|
|
|
* Hence directly printk the suite status, and we will
|
|
|
|
* separately seq_printf() the suite header for the debugfs
|
|
|
|
* representation.
|
|
|
|
*/
|
|
|
|
pr_info(KUNIT_SUBTEST_INDENT "KTAP version 1\n");
|
|
|
|
pr_info(KUNIT_SUBTEST_INDENT "# Subtest: %s\n",
|
2020-03-26 14:25:09 +00:00
|
|
|
suite->name);
|
2023-07-25 21:25:12 +00:00
|
|
|
kunit_print_attr((void *)suite, false, KUNIT_LEVEL_CASE);
|
2023-03-08 20:39:51 +00:00
|
|
|
pr_info(KUNIT_SUBTEST_INDENT "1..%zd\n",
|
2020-03-26 14:25:07 +00:00
|
|
|
kunit_suite_num_test_cases(suite));
|
2019-09-23 09:02:31 +00:00
|
|
|
}
|
|
|
|
|
2023-05-17 11:18:16 +00:00
|
|
|
static void kunit_print_ok_not_ok(struct kunit *test,
|
|
|
|
unsigned int test_level,
|
2021-06-25 06:58:12 +00:00
|
|
|
enum kunit_status status,
|
2019-09-23 09:02:31 +00:00
|
|
|
size_t test_number,
|
2021-06-25 06:58:12 +00:00
|
|
|
const char *description,
|
|
|
|
const char *directive)
|
2019-09-23 09:02:31 +00:00
|
|
|
{
|
2021-06-25 06:58:12 +00:00
|
|
|
const char *directive_header = (status == KUNIT_SKIPPED) ? " # SKIP " : "";
|
2023-05-17 11:18:16 +00:00
|
|
|
const char *directive_body = (status == KUNIT_SKIPPED) ? directive : "";
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When test is NULL assume that results are from the suite
|
|
|
|
* and today suite results are expected at level 0 only.
|
|
|
|
*/
|
|
|
|
WARN(!test && test_level, "suite test level can't be %u!\n", test_level);
|
2019-09-23 09:02:31 +00:00
|
|
|
|
2020-03-26 14:25:07 +00:00
|
|
|
/*
|
|
|
|
* We do not log the test suite results as doing so would
|
2023-03-08 20:39:51 +00:00
|
|
|
* mean debugfs display would consist of an incorrect test
|
|
|
|
* number. Hence directly printk the suite result, and we will
|
|
|
|
* separately seq_printf() the suite results for the debugfs
|
2020-03-26 14:25:07 +00:00
|
|
|
* representation.
|
|
|
|
*/
|
2023-05-17 11:18:16 +00:00
|
|
|
if (!test)
|
2022-11-23 18:25:58 +00:00
|
|
|
pr_info("%s %zd %s%s%s\n",
|
2021-06-25 06:58:12 +00:00
|
|
|
kunit_status_to_ok_not_ok(status),
|
|
|
|
test_number, description, directive_header,
|
2023-05-17 11:18:16 +00:00
|
|
|
directive_body);
|
2019-09-23 09:02:31 +00:00
|
|
|
else
|
2021-06-25 06:58:12 +00:00
|
|
|
kunit_log(KERN_INFO, test,
|
2023-05-17 11:18:16 +00:00
|
|
|
"%*s%s %zd %s%s%s",
|
|
|
|
KUNIT_INDENT_LEN * test_level, "",
|
2021-06-25 06:58:12 +00:00
|
|
|
kunit_status_to_ok_not_ok(status),
|
|
|
|
test_number, description, directive_header,
|
2023-05-17 11:18:16 +00:00
|
|
|
directive_body);
|
2019-09-23 09:02:31 +00:00
|
|
|
}
|
|
|
|
|
2021-06-25 06:58:12 +00:00
|
|
|
enum kunit_status kunit_suite_has_succeeded(struct kunit_suite *suite)
|
2019-09-23 09:02:31 +00:00
|
|
|
{
|
|
|
|
const struct kunit_case *test_case;
|
2021-06-25 06:58:12 +00:00
|
|
|
enum kunit_status status = KUNIT_SKIPPED;
|
2019-09-23 09:02:31 +00:00
|
|
|
|
2022-04-29 18:12:57 +00:00
|
|
|
if (suite->suite_init_err)
|
|
|
|
return KUNIT_FAILURE;
|
|
|
|
|
2020-03-26 14:25:07 +00:00
|
|
|
kunit_suite_for_each_test_case(suite, test_case) {
|
2021-06-25 06:58:12 +00:00
|
|
|
if (test_case->status == KUNIT_FAILURE)
|
|
|
|
return KUNIT_FAILURE;
|
|
|
|
else if (test_case->status == KUNIT_SUCCESS)
|
|
|
|
status = KUNIT_SUCCESS;
|
2020-03-26 14:25:07 +00:00
|
|
|
}
|
2019-09-23 09:02:31 +00:00
|
|
|
|
2021-06-25 06:58:12 +00:00
|
|
|
return status;
|
2019-09-23 09:02:31 +00:00
|
|
|
}
|
2020-03-26 14:25:07 +00:00
|
|
|
EXPORT_SYMBOL_GPL(kunit_suite_has_succeeded);
|
2019-09-23 09:02:31 +00:00
|
|
|
|
kunit: Reset suite count after running tests
There are some KUnit tests (KFENCE, Thunderbolt) which, for various
reasons, do not use the kunit_test_suite() macro and end up running
before the KUnit executor runs its tests. This means that their results
are printed separately, and they aren't included in the suite count used
by the executor.
This causes the executor output to be invalid TAP, however, as the suite
numbers used are no-longer 1-based, and don't match the test plan.
kunit_tool, therefore, prints a large number of warnings.
While it'd be nice to fix the tests to run in the executor, in the
meantime, reset the suite counter to 1 in __kunit_test_suites_exit.
Not only does this fix the executor, it means that if there are multiple
calls to __kunit_test_suites_init() across different tests, they'll each
get their own numbering.
kunit_tool likes this better: even if it's lacking the results for those
tests which don't use the executor (due to the lack of TAP header), the
output for the other tests is valid.
Signed-off-by: David Gow <davidgow@google.com>
Reviewed-by: Daniel Latypov <dlatypov@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-10-06 04:41:11 +00:00
|
|
|
static size_t kunit_suite_counter = 1;
|
|
|
|
|
2022-04-29 18:12:56 +00:00
|
|
|
static void kunit_print_suite_end(struct kunit_suite *suite)
|
2019-09-23 09:02:31 +00:00
|
|
|
{
|
2023-05-17 11:18:16 +00:00
|
|
|
kunit_print_ok_not_ok(NULL, KUNIT_LEVEL_SUITE,
|
2019-09-23 09:02:31 +00:00
|
|
|
kunit_suite_has_succeeded(suite),
|
|
|
|
kunit_suite_counter++,
|
2021-06-25 06:58:12 +00:00
|
|
|
suite->name,
|
|
|
|
suite->status_comment);
|
2019-09-23 09:02:31 +00:00
|
|
|
}
|
|
|
|
|
2020-03-26 14:25:07 +00:00
|
|
|
unsigned int kunit_test_case_num(struct kunit_suite *suite,
|
|
|
|
struct kunit_case *test_case)
|
2019-09-23 09:02:31 +00:00
|
|
|
{
|
2020-03-26 14:25:07 +00:00
|
|
|
struct kunit_case *tc;
|
|
|
|
unsigned int i = 1;
|
|
|
|
|
|
|
|
kunit_suite_for_each_test_case(suite, tc) {
|
|
|
|
if (tc == test_case)
|
|
|
|
return i;
|
|
|
|
i++;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
2019-09-23 09:02:31 +00:00
|
|
|
}
|
2020-03-26 14:25:07 +00:00
|
|
|
EXPORT_SYMBOL_GPL(kunit_test_case_num);
|
2019-09-23 09:02:31 +00:00
|
|
|
|
2019-09-23 09:02:35 +00:00
|
|
|
static void kunit_print_string_stream(struct kunit *test,
|
|
|
|
struct string_stream *stream)
|
|
|
|
{
|
|
|
|
struct string_stream_fragment *fragment;
|
|
|
|
char *buf;
|
|
|
|
|
2020-03-26 14:25:07 +00:00
|
|
|
if (string_stream_is_empty(stream))
|
|
|
|
return;
|
|
|
|
|
2019-09-23 09:02:35 +00:00
|
|
|
buf = string_stream_get_string(stream);
|
|
|
|
if (!buf) {
|
|
|
|
kunit_err(test,
|
|
|
|
"Could not allocate buffer, dumping stream:\n");
|
|
|
|
list_for_each_entry(fragment, &stream->fragments, node) {
|
kunit: fix failure to build without printk
Previously KUnit assumed that printk would always be present, which is
not a valid assumption to make. Fix that by removing call to
vprintk_emit, and calling printk directly.
This fixes a build error[1] reported by Randy.
For context this change comes after much discussion. My first stab[2] at
this was just to make the KUnit logging code compile out; however, it
was agreed that if we were going to use vprintk_emit, then vprintk_emit
should provide a no-op stub, which lead to my second attempt[3]. In
response to me trying to stub out vprintk_emit, Sergey Senozhatsky
suggested a way for me to remove our usage of vprintk_emit, which led to
my third attempt at solving this[4].
In my third version of this patch[4], I completely removed vprintk_emit,
as suggested by Sergey; however, there was a bit of debate over whether
Sergey's solution was the best. The debate arose due to Sergey's version
resulting in a checkpatch warning, which resulted in a debate over
correct printk usage. Joe Perches offered an alternative fix which was
somewhat less far reaching than what Sergey had suggested and
importantly relied on continuing to use %pV. Much of the debated
centered around whether %pV should be widely used, and whether Sergey's
version would result in object size bloat. Ultimately, we decided to go
with Sergey's version.
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Link[1]: https://lore.kernel.org/linux-kselftest/c7229254-0d90-d90e-f3df-5b6d6fc0b51f@infradead.org/
Link[2]: https://lore.kernel.org/linux-kselftest/20190827174932.44177-1-brendanhiggins@google.com/
Link[3]: https://lore.kernel.org/linux-kselftest/20190827234835.234473-1-brendanhiggins@google.com/
Link[4]: https://lore.kernel.org/linux-kselftest/20190828093143.163302-1-brendanhiggins@google.com/
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Tim.Bird@sony.com
Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2019-09-23 09:02:49 +00:00
|
|
|
kunit_err(test, "%s", fragment->fragment);
|
2019-09-23 09:02:35 +00:00
|
|
|
}
|
|
|
|
kunit_err(test, "\n");
|
|
|
|
} else {
|
kunit: fix failure to build without printk
Previously KUnit assumed that printk would always be present, which is
not a valid assumption to make. Fix that by removing call to
vprintk_emit, and calling printk directly.
This fixes a build error[1] reported by Randy.
For context this change comes after much discussion. My first stab[2] at
this was just to make the KUnit logging code compile out; however, it
was agreed that if we were going to use vprintk_emit, then vprintk_emit
should provide a no-op stub, which lead to my second attempt[3]. In
response to me trying to stub out vprintk_emit, Sergey Senozhatsky
suggested a way for me to remove our usage of vprintk_emit, which led to
my third attempt at solving this[4].
In my third version of this patch[4], I completely removed vprintk_emit,
as suggested by Sergey; however, there was a bit of debate over whether
Sergey's solution was the best. The debate arose due to Sergey's version
resulting in a checkpatch warning, which resulted in a debate over
correct printk usage. Joe Perches offered an alternative fix which was
somewhat less far reaching than what Sergey had suggested and
importantly relied on continuing to use %pV. Much of the debated
centered around whether %pV should be widely used, and whether Sergey's
version would result in object size bloat. Ultimately, we decided to go
with Sergey's version.
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Link[1]: https://lore.kernel.org/linux-kselftest/c7229254-0d90-d90e-f3df-5b6d6fc0b51f@infradead.org/
Link[2]: https://lore.kernel.org/linux-kselftest/20190827174932.44177-1-brendanhiggins@google.com/
Link[3]: https://lore.kernel.org/linux-kselftest/20190827234835.234473-1-brendanhiggins@google.com/
Link[4]: https://lore.kernel.org/linux-kselftest/20190828093143.163302-1-brendanhiggins@google.com/
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Tim.Bird@sony.com
Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2019-09-23 09:02:49 +00:00
|
|
|
kunit_err(test, "%s", buf);
|
2023-08-28 10:41:08 +00:00
|
|
|
kfree(buf);
|
2019-09-23 09:02:35 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
kunit: split out part of kunit_assert into a static const
This is per Linus's suggestion in [1].
The issue there is that every KUNIT_EXPECT/KUNIT_ASSERT puts a
kunit_assert object onto the stack. Normally we rely on compilers to
elide this, but when that doesn't work out, this blows up the stack
usage of kunit test functions.
We can move some data off the stack by making it static.
This change introduces a new `struct kunit_loc` to hold the file and
line number and then just passing assert_type (EXPECT or ASSERT) as an
argument.
In [1], it was suggested to also move out the format string as well, but
users could theoretically craft a format string at runtime, so we can't.
This change leaves a copy of `assert_type` in kunit_assert for now
because cleaning up all the macros to not pass it around is a bit more
involved.
Here's an example of the expanded code for KUNIT_FAIL():
if (__builtin_expect(!!(!(false)), 0)) {
static const struct kunit_loc loc = { .file = ... };
struct kunit_fail_assert __assertion = { .assert = { .type ... };
kunit_do_failed_assertion(test, &loc, KUNIT_EXPECTATION, &__assertion.assert, ...);
};
[1] https://groups.google.com/g/kunit-dev/c/i3fZXgvBrfA/m/VULQg1z6BAAJ
Signed-off-by: Daniel Latypov <dlatypov@google.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Reviewed-by: David Gow <davidgow@google.com>
Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-01-13 16:59:30 +00:00
|
|
|
static void kunit_fail(struct kunit *test, const struct kunit_loc *loc,
|
2022-05-02 09:36:25 +00:00
|
|
|
enum kunit_assert_type type, const struct kunit_assert *assert,
|
2022-10-01 00:26:35 +00:00
|
|
|
assert_format_t assert_format, const struct va_format *message)
|
2019-09-23 09:02:35 +00:00
|
|
|
{
|
|
|
|
struct string_stream *stream;
|
|
|
|
|
|
|
|
kunit_set_failure(test);
|
|
|
|
|
2023-08-28 10:41:07 +00:00
|
|
|
stream = kunit_alloc_string_stream(test, GFP_KERNEL);
|
2022-10-14 09:37:25 +00:00
|
|
|
if (IS_ERR(stream)) {
|
2019-09-23 09:02:35 +00:00
|
|
|
WARN(true,
|
|
|
|
"Could not allocate stream to print failed assertion in %s:%d\n",
|
kunit: split out part of kunit_assert into a static const
This is per Linus's suggestion in [1].
The issue there is that every KUNIT_EXPECT/KUNIT_ASSERT puts a
kunit_assert object onto the stack. Normally we rely on compilers to
elide this, but when that doesn't work out, this blows up the stack
usage of kunit test functions.
We can move some data off the stack by making it static.
This change introduces a new `struct kunit_loc` to hold the file and
line number and then just passing assert_type (EXPECT or ASSERT) as an
argument.
In [1], it was suggested to also move out the format string as well, but
users could theoretically craft a format string at runtime, so we can't.
This change leaves a copy of `assert_type` in kunit_assert for now
because cleaning up all the macros to not pass it around is a bit more
involved.
Here's an example of the expanded code for KUNIT_FAIL():
if (__builtin_expect(!!(!(false)), 0)) {
static const struct kunit_loc loc = { .file = ... };
struct kunit_fail_assert __assertion = { .assert = { .type ... };
kunit_do_failed_assertion(test, &loc, KUNIT_EXPECTATION, &__assertion.assert, ...);
};
[1] https://groups.google.com/g/kunit-dev/c/i3fZXgvBrfA/m/VULQg1z6BAAJ
Signed-off-by: Daniel Latypov <dlatypov@google.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Reviewed-by: David Gow <davidgow@google.com>
Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-01-13 16:59:30 +00:00
|
|
|
loc->file,
|
|
|
|
loc->line);
|
2019-09-23 09:02:35 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
kunit: split out part of kunit_assert into a static const
This is per Linus's suggestion in [1].
The issue there is that every KUNIT_EXPECT/KUNIT_ASSERT puts a
kunit_assert object onto the stack. Normally we rely on compilers to
elide this, but when that doesn't work out, this blows up the stack
usage of kunit test functions.
We can move some data off the stack by making it static.
This change introduces a new `struct kunit_loc` to hold the file and
line number and then just passing assert_type (EXPECT or ASSERT) as an
argument.
In [1], it was suggested to also move out the format string as well, but
users could theoretically craft a format string at runtime, so we can't.
This change leaves a copy of `assert_type` in kunit_assert for now
because cleaning up all the macros to not pass it around is a bit more
involved.
Here's an example of the expanded code for KUNIT_FAIL():
if (__builtin_expect(!!(!(false)), 0)) {
static const struct kunit_loc loc = { .file = ... };
struct kunit_fail_assert __assertion = { .assert = { .type ... };
kunit_do_failed_assertion(test, &loc, KUNIT_EXPECTATION, &__assertion.assert, ...);
};
[1] https://groups.google.com/g/kunit-dev/c/i3fZXgvBrfA/m/VULQg1z6BAAJ
Signed-off-by: Daniel Latypov <dlatypov@google.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Reviewed-by: David Gow <davidgow@google.com>
Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-01-13 16:59:30 +00:00
|
|
|
kunit_assert_prologue(loc, type, stream);
|
2022-10-01 00:26:35 +00:00
|
|
|
assert_format(assert, message, stream);
|
2019-09-23 09:02:35 +00:00
|
|
|
|
|
|
|
kunit_print_string_stream(test, stream);
|
|
|
|
|
2023-08-28 10:41:07 +00:00
|
|
|
kunit_free_string_stream(test, stream);
|
2019-09-23 09:02:35 +00:00
|
|
|
}
|
|
|
|
|
2023-05-31 05:21:57 +00:00
|
|
|
void __noreturn __kunit_abort(struct kunit *test)
|
2019-09-23 09:02:39 +00:00
|
|
|
{
|
|
|
|
kunit_try_catch_throw(&test->try_catch); /* Does not return. */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Throw could not abort from test.
|
|
|
|
*
|
|
|
|
* XXX: we should never reach this line! As kunit_try_catch_throw is
|
|
|
|
* marked __noreturn.
|
|
|
|
*/
|
|
|
|
WARN_ONCE(true, "Throw could not abort from test!\n");
|
|
|
|
}
|
2023-05-31 05:21:57 +00:00
|
|
|
EXPORT_SYMBOL_GPL(__kunit_abort);
|
2019-09-23 09:02:39 +00:00
|
|
|
|
2023-05-31 05:21:57 +00:00
|
|
|
void __kunit_do_failed_assertion(struct kunit *test,
|
kunit: split out part of kunit_assert into a static const
This is per Linus's suggestion in [1].
The issue there is that every KUNIT_EXPECT/KUNIT_ASSERT puts a
kunit_assert object onto the stack. Normally we rely on compilers to
elide this, but when that doesn't work out, this blows up the stack
usage of kunit test functions.
We can move some data off the stack by making it static.
This change introduces a new `struct kunit_loc` to hold the file and
line number and then just passing assert_type (EXPECT or ASSERT) as an
argument.
In [1], it was suggested to also move out the format string as well, but
users could theoretically craft a format string at runtime, so we can't.
This change leaves a copy of `assert_type` in kunit_assert for now
because cleaning up all the macros to not pass it around is a bit more
involved.
Here's an example of the expanded code for KUNIT_FAIL():
if (__builtin_expect(!!(!(false)), 0)) {
static const struct kunit_loc loc = { .file = ... };
struct kunit_fail_assert __assertion = { .assert = { .type ... };
kunit_do_failed_assertion(test, &loc, KUNIT_EXPECTATION, &__assertion.assert, ...);
};
[1] https://groups.google.com/g/kunit-dev/c/i3fZXgvBrfA/m/VULQg1z6BAAJ
Signed-off-by: Daniel Latypov <dlatypov@google.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Reviewed-by: David Gow <davidgow@google.com>
Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-01-13 16:59:30 +00:00
|
|
|
const struct kunit_loc *loc,
|
|
|
|
enum kunit_assert_type type,
|
2022-05-02 09:36:25 +00:00
|
|
|
const struct kunit_assert *assert,
|
2022-10-01 00:26:35 +00:00
|
|
|
assert_format_t assert_format,
|
2022-01-13 16:59:27 +00:00
|
|
|
const char *fmt, ...)
|
2019-09-23 09:02:35 +00:00
|
|
|
{
|
|
|
|
va_list args;
|
2022-01-25 21:00:09 +00:00
|
|
|
struct va_format message;
|
2019-09-23 09:02:35 +00:00
|
|
|
va_start(args, fmt);
|
|
|
|
|
2022-01-25 21:00:09 +00:00
|
|
|
message.fmt = fmt;
|
|
|
|
message.va = &args;
|
2019-09-23 09:02:35 +00:00
|
|
|
|
2022-10-01 00:26:35 +00:00
|
|
|
kunit_fail(test, loc, type, assert, assert_format, &message);
|
2019-09-23 09:02:35 +00:00
|
|
|
|
|
|
|
va_end(args);
|
|
|
|
}
|
2023-05-31 05:21:57 +00:00
|
|
|
EXPORT_SYMBOL_GPL(__kunit_do_failed_assertion);
|
2019-09-23 09:02:35 +00:00
|
|
|
|
2023-08-28 10:41:10 +00:00
|
|
|
void kunit_init_test(struct kunit *test, const char *name, struct string_stream *log)
|
2019-09-23 09:02:31 +00:00
|
|
|
{
|
2019-09-23 09:02:32 +00:00
|
|
|
spin_lock_init(&test->lock);
|
|
|
|
INIT_LIST_HEAD(&test->resources);
|
2019-09-23 09:02:31 +00:00
|
|
|
test->name = name;
|
2020-03-26 14:25:07 +00:00
|
|
|
test->log = log;
|
|
|
|
if (test->log)
|
2023-08-28 10:41:10 +00:00
|
|
|
string_stream_clear(log);
|
2021-06-25 06:58:12 +00:00
|
|
|
test->status = KUNIT_SUCCESS;
|
|
|
|
test->status_comment[0] = '\0';
|
2019-09-23 09:02:31 +00:00
|
|
|
}
|
2020-01-06 22:28:20 +00:00
|
|
|
EXPORT_SYMBOL_GPL(kunit_init_test);
|
2019-09-23 09:02:31 +00:00
|
|
|
|
|
|
|
/*
|
2019-09-23 09:02:39 +00:00
|
|
|
* Initializes and runs test case. Does not clean up or do post validations.
|
2019-09-23 09:02:31 +00:00
|
|
|
*/
|
2019-09-23 09:02:39 +00:00
|
|
|
static void kunit_run_case_internal(struct kunit *test,
|
|
|
|
struct kunit_suite *suite,
|
|
|
|
struct kunit_case *test_case)
|
2019-09-23 09:02:31 +00:00
|
|
|
{
|
|
|
|
if (suite->init) {
|
|
|
|
int ret;
|
|
|
|
|
2019-09-23 09:02:39 +00:00
|
|
|
ret = suite->init(test);
|
2019-09-23 09:02:31 +00:00
|
|
|
if (ret) {
|
2019-09-23 09:02:39 +00:00
|
|
|
kunit_err(test, "failed to initialize: %d\n", ret);
|
|
|
|
kunit_set_failure(test);
|
2019-09-23 09:02:31 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-09-23 09:02:39 +00:00
|
|
|
test_case->run_case(test);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void kunit_case_internal_cleanup(struct kunit *test)
|
|
|
|
{
|
|
|
|
kunit_cleanup(test);
|
|
|
|
}
|
2019-09-23 09:02:31 +00:00
|
|
|
|
2019-09-23 09:02:39 +00:00
|
|
|
/*
|
|
|
|
* Performs post validations and cleanup after a test case was run.
|
|
|
|
* XXX: Should ONLY BE CALLED AFTER kunit_run_case_internal!
|
|
|
|
*/
|
|
|
|
static void kunit_run_case_cleanup(struct kunit *test,
|
|
|
|
struct kunit_suite *suite)
|
|
|
|
{
|
2019-09-23 09:02:31 +00:00
|
|
|
if (suite->exit)
|
2019-09-23 09:02:39 +00:00
|
|
|
suite->exit(test);
|
|
|
|
|
|
|
|
kunit_case_internal_cleanup(test);
|
|
|
|
}
|
|
|
|
|
|
|
|
struct kunit_try_catch_context {
|
|
|
|
struct kunit *test;
|
|
|
|
struct kunit_suite *suite;
|
|
|
|
struct kunit_case *test_case;
|
|
|
|
};
|
|
|
|
|
|
|
|
static void kunit_try_run_case(void *data)
|
|
|
|
{
|
|
|
|
struct kunit_try_catch_context *ctx = data;
|
|
|
|
struct kunit *test = ctx->test;
|
|
|
|
struct kunit_suite *suite = ctx->suite;
|
|
|
|
struct kunit_case *test_case = ctx->test_case;
|
|
|
|
|
2020-10-13 23:55:02 +00:00
|
|
|
current->kunit_test = test;
|
|
|
|
|
2019-09-23 09:02:39 +00:00
|
|
|
/*
|
|
|
|
* kunit_run_case_internal may encounter a fatal error; if it does,
|
|
|
|
* abort will be called, this thread will exit, and finally the parent
|
|
|
|
* thread will resume control and handle any necessary clean up.
|
|
|
|
*/
|
|
|
|
kunit_run_case_internal(test, suite, test_case);
|
kunit: Always run cleanup from a test kthread
KUnit tests run in a kthread, with the current->kunit_test pointer set
to the test's context. This allows the kunit_get_current_test() and
kunit_fail_current_test() macros to work. Normally, this pointer is
still valid during test shutdown (i.e., the suite->exit function, and
any resource cleanup). However, if the test has exited early (e.g., due
to a failed assertion), the cleanup is done in the parent KUnit thread,
which does not have an active context.
Instead, in the event test terminates early, run the test exit and
cleanup from a new 'cleanup' kthread, which sets current->kunit_test,
and better isolates the rest of KUnit from issues which arise in test
cleanup.
If a test cleanup function itself aborts (e.g., due to an assertion
failing), there will be no further attempts to clean up: an error will
be logged and the test failed. For example:
# example_simple_test: test aborted during cleanup. continuing without cleaning up
This should also make it easier to get access to the KUnit context,
particularly from within resource cleanup functions, which may, for
example, need access to data in test->priv.
Reviewed-by: Benjamin Berg <benjamin.berg@intel.com>
Reviewed-by: Maxime Ripard <maxime@cerno.tech>
Tested-by: Maxime Ripard <maxime@cerno.tech>
Signed-off-by: David Gow <davidgow@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2023-05-10 05:38:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void kunit_try_run_case_cleanup(void *data)
|
|
|
|
{
|
|
|
|
struct kunit_try_catch_context *ctx = data;
|
|
|
|
struct kunit *test = ctx->test;
|
|
|
|
struct kunit_suite *suite = ctx->suite;
|
|
|
|
|
|
|
|
current->kunit_test = test;
|
|
|
|
|
2019-09-23 09:02:39 +00:00
|
|
|
kunit_run_case_cleanup(test, suite);
|
|
|
|
}
|
|
|
|
|
kunit: Always run cleanup from a test kthread
KUnit tests run in a kthread, with the current->kunit_test pointer set
to the test's context. This allows the kunit_get_current_test() and
kunit_fail_current_test() macros to work. Normally, this pointer is
still valid during test shutdown (i.e., the suite->exit function, and
any resource cleanup). However, if the test has exited early (e.g., due
to a failed assertion), the cleanup is done in the parent KUnit thread,
which does not have an active context.
Instead, in the event test terminates early, run the test exit and
cleanup from a new 'cleanup' kthread, which sets current->kunit_test,
and better isolates the rest of KUnit from issues which arise in test
cleanup.
If a test cleanup function itself aborts (e.g., due to an assertion
failing), there will be no further attempts to clean up: an error will
be logged and the test failed. For example:
# example_simple_test: test aborted during cleanup. continuing without cleaning up
This should also make it easier to get access to the KUnit context,
particularly from within resource cleanup functions, which may, for
example, need access to data in test->priv.
Reviewed-by: Benjamin Berg <benjamin.berg@intel.com>
Reviewed-by: Maxime Ripard <maxime@cerno.tech>
Tested-by: Maxime Ripard <maxime@cerno.tech>
Signed-off-by: David Gow <davidgow@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2023-05-10 05:38:29 +00:00
|
|
|
static void kunit_catch_run_case_cleanup(void *data)
|
|
|
|
{
|
|
|
|
struct kunit_try_catch_context *ctx = data;
|
|
|
|
struct kunit *test = ctx->test;
|
|
|
|
int try_exit_code = kunit_try_catch_get_result(&test->try_catch);
|
|
|
|
|
|
|
|
/* It is always a failure if cleanup aborts. */
|
|
|
|
kunit_set_failure(test);
|
|
|
|
|
|
|
|
if (try_exit_code) {
|
|
|
|
/*
|
|
|
|
* Test case could not finish, we have no idea what state it is
|
|
|
|
* in, so don't do clean up.
|
|
|
|
*/
|
|
|
|
if (try_exit_code == -ETIMEDOUT) {
|
|
|
|
kunit_err(test, "test case cleanup timed out\n");
|
|
|
|
/*
|
|
|
|
* Unknown internal error occurred preventing test case from
|
|
|
|
* running, so there is nothing to clean up.
|
|
|
|
*/
|
|
|
|
} else {
|
|
|
|
kunit_err(test, "internal error occurred during test case cleanup: %d\n",
|
|
|
|
try_exit_code);
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
kunit_err(test, "test aborted during cleanup. continuing without cleaning up\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2019-09-23 09:02:39 +00:00
|
|
|
static void kunit_catch_run_case(void *data)
|
|
|
|
{
|
|
|
|
struct kunit_try_catch_context *ctx = data;
|
|
|
|
struct kunit *test = ctx->test;
|
|
|
|
int try_exit_code = kunit_try_catch_get_result(&test->try_catch);
|
|
|
|
|
|
|
|
if (try_exit_code) {
|
|
|
|
kunit_set_failure(test);
|
|
|
|
/*
|
|
|
|
* Test case could not finish, we have no idea what state it is
|
|
|
|
* in, so don't do clean up.
|
|
|
|
*/
|
|
|
|
if (try_exit_code == -ETIMEDOUT) {
|
|
|
|
kunit_err(test, "test case timed out\n");
|
|
|
|
/*
|
|
|
|
* Unknown internal error occurred preventing test case from
|
|
|
|
* running, so there is nothing to clean up.
|
|
|
|
*/
|
|
|
|
} else {
|
|
|
|
kunit_err(test, "internal error occurred preventing test case from running: %d\n",
|
|
|
|
try_exit_code);
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Performs all logic to run a test case. It also catches most errors that
|
|
|
|
* occur in a test case and reports them as failures.
|
|
|
|
*/
|
|
|
|
static void kunit_run_case_catch_errors(struct kunit_suite *suite,
|
2020-11-16 05:40:35 +00:00
|
|
|
struct kunit_case *test_case,
|
|
|
|
struct kunit *test)
|
2019-09-23 09:02:39 +00:00
|
|
|
{
|
|
|
|
struct kunit_try_catch_context context;
|
|
|
|
struct kunit_try_catch *try_catch;
|
|
|
|
|
2020-11-16 05:40:35 +00:00
|
|
|
try_catch = &test->try_catch;
|
2019-09-23 09:02:31 +00:00
|
|
|
|
2019-09-23 09:02:39 +00:00
|
|
|
kunit_try_catch_init(try_catch,
|
2020-11-16 05:40:35 +00:00
|
|
|
test,
|
2019-09-23 09:02:39 +00:00
|
|
|
kunit_try_run_case,
|
|
|
|
kunit_catch_run_case);
|
2020-11-16 05:40:35 +00:00
|
|
|
context.test = test;
|
2019-09-23 09:02:39 +00:00
|
|
|
context.suite = suite;
|
|
|
|
context.test_case = test_case;
|
|
|
|
kunit_try_catch_run(try_catch, &context);
|
2019-09-23 09:02:32 +00:00
|
|
|
|
kunit: Always run cleanup from a test kthread
KUnit tests run in a kthread, with the current->kunit_test pointer set
to the test's context. This allows the kunit_get_current_test() and
kunit_fail_current_test() macros to work. Normally, this pointer is
still valid during test shutdown (i.e., the suite->exit function, and
any resource cleanup). However, if the test has exited early (e.g., due
to a failed assertion), the cleanup is done in the parent KUnit thread,
which does not have an active context.
Instead, in the event test terminates early, run the test exit and
cleanup from a new 'cleanup' kthread, which sets current->kunit_test,
and better isolates the rest of KUnit from issues which arise in test
cleanup.
If a test cleanup function itself aborts (e.g., due to an assertion
failing), there will be no further attempts to clean up: an error will
be logged and the test failed. For example:
# example_simple_test: test aborted during cleanup. continuing without cleaning up
This should also make it easier to get access to the KUnit context,
particularly from within resource cleanup functions, which may, for
example, need access to data in test->priv.
Reviewed-by: Benjamin Berg <benjamin.berg@intel.com>
Reviewed-by: Maxime Ripard <maxime@cerno.tech>
Tested-by: Maxime Ripard <maxime@cerno.tech>
Signed-off-by: David Gow <davidgow@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2023-05-10 05:38:29 +00:00
|
|
|
/* Now run the cleanup */
|
|
|
|
kunit_try_catch_init(try_catch,
|
|
|
|
test,
|
|
|
|
kunit_try_run_case_cleanup,
|
|
|
|
kunit_catch_run_case_cleanup);
|
|
|
|
kunit_try_catch_run(try_catch, &context);
|
|
|
|
|
2021-06-25 06:58:12 +00:00
|
|
|
/* Propagate the parameter result to the test case. */
|
|
|
|
if (test->status == KUNIT_FAILURE)
|
|
|
|
test_case->status = KUNIT_FAILURE;
|
|
|
|
else if (test_case->status != KUNIT_FAILURE && test->status == KUNIT_SUCCESS)
|
|
|
|
test_case->status = KUNIT_SUCCESS;
|
2019-09-23 09:02:31 +00:00
|
|
|
}
|
|
|
|
|
2021-08-04 05:08:08 +00:00
|
|
|
static void kunit_print_suite_stats(struct kunit_suite *suite,
|
|
|
|
struct kunit_result_stats suite_stats,
|
|
|
|
struct kunit_result_stats param_stats)
|
|
|
|
{
|
|
|
|
if (kunit_should_print_stats(suite_stats)) {
|
|
|
|
kunit_log(KERN_INFO, suite,
|
|
|
|
"# %s: pass:%lu fail:%lu skip:%lu total:%lu",
|
|
|
|
suite->name,
|
|
|
|
suite_stats.passed,
|
|
|
|
suite_stats.failed,
|
|
|
|
suite_stats.skipped,
|
|
|
|
suite_stats.total);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (kunit_should_print_stats(param_stats)) {
|
|
|
|
kunit_log(KERN_INFO, suite,
|
|
|
|
"# Totals: pass:%lu fail:%lu skip:%lu total:%lu",
|
|
|
|
param_stats.passed,
|
|
|
|
param_stats.failed,
|
|
|
|
param_stats.skipped,
|
|
|
|
param_stats.total);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void kunit_update_stats(struct kunit_result_stats *stats,
|
|
|
|
enum kunit_status status)
|
|
|
|
{
|
|
|
|
switch (status) {
|
|
|
|
case KUNIT_SUCCESS:
|
|
|
|
stats->passed++;
|
|
|
|
break;
|
|
|
|
case KUNIT_SKIPPED:
|
|
|
|
stats->skipped++;
|
|
|
|
break;
|
|
|
|
case KUNIT_FAILURE:
|
|
|
|
stats->failed++;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
stats->total++;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void kunit_accumulate_stats(struct kunit_result_stats *total,
|
|
|
|
struct kunit_result_stats add)
|
|
|
|
{
|
|
|
|
total->passed += add.passed;
|
|
|
|
total->skipped += add.skipped;
|
|
|
|
total->failed += add.failed;
|
|
|
|
total->total += add.total;
|
|
|
|
}
|
|
|
|
|
2019-09-23 09:02:31 +00:00
|
|
|
int kunit_run_tests(struct kunit_suite *suite)
|
|
|
|
{
|
2020-11-16 05:40:35 +00:00
|
|
|
char param_desc[KUNIT_PARAM_DESC_SIZE];
|
2019-09-23 09:02:31 +00:00
|
|
|
struct kunit_case *test_case;
|
2021-08-04 05:08:08 +00:00
|
|
|
struct kunit_result_stats suite_stats = { 0 };
|
|
|
|
struct kunit_result_stats total_stats = { 0 };
|
2019-09-23 09:02:31 +00:00
|
|
|
|
2022-07-01 08:47:43 +00:00
|
|
|
/* Taint the kernel so we know we've run tests. */
|
|
|
|
add_taint(TAINT_TEST, LOCKDEP_STILL_OK);
|
|
|
|
|
2022-04-29 18:12:57 +00:00
|
|
|
if (suite->suite_init) {
|
|
|
|
suite->suite_init_err = suite->suite_init(suite);
|
|
|
|
if (suite->suite_init_err) {
|
|
|
|
kunit_err(suite, KUNIT_SUBTEST_INDENT
|
|
|
|
"# failed to initialize (%d)", suite->suite_init_err);
|
|
|
|
goto suite_end;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-04-29 18:12:56 +00:00
|
|
|
kunit_print_suite_start(suite);
|
2019-09-23 09:02:31 +00:00
|
|
|
|
2020-11-16 05:40:35 +00:00
|
|
|
kunit_suite_for_each_test_case(suite, test_case) {
|
|
|
|
struct kunit test = { .param_value = NULL, .param_index = 0 };
|
2021-08-04 05:08:08 +00:00
|
|
|
struct kunit_result_stats param_stats = { 0 };
|
2020-11-16 05:40:35 +00:00
|
|
|
|
2023-03-08 20:39:50 +00:00
|
|
|
kunit_init_test(&test, test_case->name, test_case->log);
|
kunit: Add ability to filter attributes
Add filtering of test attributes. Users can filter tests using the
module_param called "filter".
Filters are imputed in the format: <attribute_name><operation><value>
Example: kunit.filter="speed>slow"
Operations include: >, <, >=, <=, !=, and =. These operations will act the
same for attributes of the same type but may not between types.
Note multiple filters can be inputted by separating them with a comma.
Example: kunit.filter="speed=slow, module!=example"
Since both suites and test cases can have attributes, there may be
conflicts. The process of filtering follows these rules:
- Filtering always operates at a per-test level.
- If a test has an attribute set, then the test's value is filtered on.
- Otherwise, the value falls back to the suite's value.
- If neither are set, the attribute has a global "default" value, which
is used.
Filtered tests will not be run or show in output. The tests can instead be
skipped using the configurable option "kunit.filter_action=skip".
Note the default settings for running tests remains unfiltered.
Finally, add "filter" methods for the speed and module attributes to parse
and compare attribute values.
Note this filtering functionality will be added to kunit.py in the next
patch.
Reviewed-by: David Gow <davidgow@google.com>
Signed-off-by: Rae Moar <rmoar@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2023-07-25 21:25:15 +00:00
|
|
|
if (test_case->status == KUNIT_SKIPPED) {
|
|
|
|
/* Test marked as skip */
|
|
|
|
test.status = KUNIT_SKIPPED;
|
|
|
|
kunit_update_stats(¶m_stats, test.status);
|
|
|
|
} else if (!test_case->generate_params) {
|
2021-11-02 07:30:13 +00:00
|
|
|
/* Non-parameterised test. */
|
kunit: Add ability to filter attributes
Add filtering of test attributes. Users can filter tests using the
module_param called "filter".
Filters are imputed in the format: <attribute_name><operation><value>
Example: kunit.filter="speed>slow"
Operations include: >, <, >=, <=, !=, and =. These operations will act the
same for attributes of the same type but may not between types.
Note multiple filters can be inputted by separating them with a comma.
Example: kunit.filter="speed=slow, module!=example"
Since both suites and test cases can have attributes, there may be
conflicts. The process of filtering follows these rules:
- Filtering always operates at a per-test level.
- If a test has an attribute set, then the test's value is filtered on.
- Otherwise, the value falls back to the suite's value.
- If neither are set, the attribute has a global "default" value, which
is used.
Filtered tests will not be run or show in output. The tests can instead be
skipped using the configurable option "kunit.filter_action=skip".
Note the default settings for running tests remains unfiltered.
Finally, add "filter" methods for the speed and module attributes to parse
and compare attribute values.
Note this filtering functionality will be added to kunit.py in the next
patch.
Reviewed-by: David Gow <davidgow@google.com>
Signed-off-by: Rae Moar <rmoar@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2023-07-25 21:25:15 +00:00
|
|
|
test_case->status = KUNIT_SKIPPED;
|
2021-11-02 07:30:13 +00:00
|
|
|
kunit_run_case_catch_errors(suite, test_case, &test);
|
|
|
|
kunit_update_stats(¶m_stats, test.status);
|
|
|
|
} else {
|
2020-11-16 05:40:35 +00:00
|
|
|
/* Get initial param. */
|
|
|
|
param_desc[0] = '\0';
|
|
|
|
test.param_value = test_case->generate_params(NULL, param_desc);
|
kunit: Add ability to filter attributes
Add filtering of test attributes. Users can filter tests using the
module_param called "filter".
Filters are imputed in the format: <attribute_name><operation><value>
Example: kunit.filter="speed>slow"
Operations include: >, <, >=, <=, !=, and =. These operations will act the
same for attributes of the same type but may not between types.
Note multiple filters can be inputted by separating them with a comma.
Example: kunit.filter="speed=slow, module!=example"
Since both suites and test cases can have attributes, there may be
conflicts. The process of filtering follows these rules:
- Filtering always operates at a per-test level.
- If a test has an attribute set, then the test's value is filtered on.
- Otherwise, the value falls back to the suite's value.
- If neither are set, the attribute has a global "default" value, which
is used.
Filtered tests will not be run or show in output. The tests can instead be
skipped using the configurable option "kunit.filter_action=skip".
Note the default settings for running tests remains unfiltered.
Finally, add "filter" methods for the speed and module attributes to parse
and compare attribute values.
Note this filtering functionality will be added to kunit.py in the next
patch.
Reviewed-by: David Gow <davidgow@google.com>
Signed-off-by: Rae Moar <rmoar@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2023-07-25 21:25:15 +00:00
|
|
|
test_case->status = KUNIT_SKIPPED;
|
2022-11-23 18:25:58 +00:00
|
|
|
kunit_log(KERN_INFO, &test, KUNIT_SUBTEST_INDENT KUNIT_SUBTEST_INDENT
|
|
|
|
"KTAP version 1\n");
|
kunit: Report test parameter results as (K)TAP subtests
Currently, the results for individial parameters in a parameterised test
are simply output as (K)TAP diagnostic lines.
As kunit_tool now supports nested subtests, report each parameter as its
own subtest.
For example, here's what the output now looks like:
# Subtest: inode_test_xtimestamp_decoding
ok 1 - 1901-12-13 Lower bound of 32bit < 0 timestamp, no extra bits
ok 2 - 1969-12-31 Upper bound of 32bit < 0 timestamp, no extra bits
ok 3 - 1970-01-01 Lower bound of 32bit >=0 timestamp, no extra bits
ok 4 - 2038-01-19 Upper bound of 32bit >=0 timestamp, no extra bits
ok 5 - 2038-01-19 Lower bound of 32bit <0 timestamp, lo extra sec bit on
ok 6 - 2106-02-07 Upper bound of 32bit <0 timestamp, lo extra sec bit on
ok 7 - 2106-02-07 Lower bound of 32bit >=0 timestamp, lo extra sec bit on
ok 8 - 2174-02-25 Upper bound of 32bit >=0 timestamp, lo extra sec bit on
ok 9 - 2174-02-25 Lower bound of 32bit <0 timestamp, hi extra sec bit on
ok 10 - 2242-03-16 Upper bound of 32bit <0 timestamp, hi extra sec bit on
ok 11 - 2242-03-16 Lower bound of 32bit >=0 timestamp, hi extra sec bit on
ok 12 - 2310-04-04 Upper bound of 32bit >=0 timestamp, hi extra sec bit on
ok 13 - 2310-04-04 Upper bound of 32bit>=0 timestamp, hi extra sec bit 1. 1 ns
ok 14 - 2378-04-22 Lower bound of 32bit>= timestamp. Extra sec bits 1. Max ns
ok 15 - 2378-04-22 Lower bound of 32bit >=0 timestamp. All extra sec bits on
ok 16 - 2446-05-10 Upper bound of 32bit >=0 timestamp. All extra sec bits on
# inode_test_xtimestamp_decoding: pass:16 fail:0 skip:0 total:16
ok 1 - inode_test_xtimestamp_decoding
Signed-off-by: David Gow <davidgow@google.com>
Reviewed-by: Daniel Latypov <dlatypov@google.com>
Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-11-02 07:30:14 +00:00
|
|
|
kunit_log(KERN_INFO, &test, KUNIT_SUBTEST_INDENT KUNIT_SUBTEST_INDENT
|
|
|
|
"# Subtest: %s", test_case->name);
|
2020-11-16 05:40:35 +00:00
|
|
|
|
2021-11-02 07:30:13 +00:00
|
|
|
while (test.param_value) {
|
|
|
|
kunit_run_case_catch_errors(suite, test_case, &test);
|
2020-11-16 05:40:35 +00:00
|
|
|
|
|
|
|
if (param_desc[0] == '\0') {
|
|
|
|
snprintf(param_desc, sizeof(param_desc),
|
|
|
|
"param-%d", test.param_index);
|
|
|
|
}
|
|
|
|
|
2023-05-17 11:18:16 +00:00
|
|
|
kunit_print_ok_not_ok(&test, KUNIT_LEVEL_CASE_PARAM,
|
|
|
|
test.status,
|
|
|
|
test.param_index + 1,
|
|
|
|
param_desc,
|
|
|
|
test.status_comment);
|
2020-11-16 05:40:35 +00:00
|
|
|
|
2023-08-31 21:48:47 +00:00
|
|
|
kunit_update_stats(¶m_stats, test.status);
|
|
|
|
|
2020-11-16 05:40:35 +00:00
|
|
|
/* Get next param. */
|
|
|
|
param_desc[0] = '\0';
|
|
|
|
test.param_value = test_case->generate_params(test.param_value, param_desc);
|
|
|
|
test.param_index++;
|
2023-08-31 21:48:47 +00:00
|
|
|
test.status = KUNIT_SUCCESS;
|
|
|
|
test.status_comment[0] = '\0';
|
2021-11-02 07:30:13 +00:00
|
|
|
}
|
|
|
|
}
|
2021-08-04 05:08:08 +00:00
|
|
|
|
2023-07-25 21:25:12 +00:00
|
|
|
kunit_print_attr((void *)test_case, true, KUNIT_LEVEL_CASE);
|
2020-11-16 05:40:35 +00:00
|
|
|
|
2021-08-04 05:08:08 +00:00
|
|
|
kunit_print_test_stats(&test, param_stats);
|
|
|
|
|
2023-05-17 11:18:16 +00:00
|
|
|
kunit_print_ok_not_ok(&test, KUNIT_LEVEL_CASE, test_case->status,
|
2020-11-16 05:40:35 +00:00
|
|
|
kunit_test_case_num(suite, test_case),
|
2021-06-25 06:58:12 +00:00
|
|
|
test_case->name,
|
|
|
|
test.status_comment);
|
2021-08-04 05:08:08 +00:00
|
|
|
|
|
|
|
kunit_update_stats(&suite_stats, test_case->status);
|
|
|
|
kunit_accumulate_stats(&total_stats, param_stats);
|
2020-11-16 05:40:35 +00:00
|
|
|
}
|
2019-09-23 09:02:31 +00:00
|
|
|
|
2022-04-29 18:12:57 +00:00
|
|
|
if (suite->suite_exit)
|
|
|
|
suite->suite_exit(suite);
|
|
|
|
|
2021-08-04 05:08:08 +00:00
|
|
|
kunit_print_suite_stats(suite, suite_stats, total_stats);
|
2022-04-29 18:12:57 +00:00
|
|
|
suite_end:
|
2022-04-29 18:12:56 +00:00
|
|
|
kunit_print_suite_end(suite);
|
2019-09-23 09:02:31 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2020-01-06 22:28:20 +00:00
|
|
|
EXPORT_SYMBOL_GPL(kunit_run_tests);
|
2019-09-23 09:02:31 +00:00
|
|
|
|
2020-03-26 14:25:07 +00:00
|
|
|
static void kunit_init_suite(struct kunit_suite *suite)
|
|
|
|
{
|
|
|
|
kunit_debugfs_create_suite(suite);
|
2021-06-25 06:58:12 +00:00
|
|
|
suite->status_comment[0] = '\0';
|
2022-04-29 18:12:57 +00:00
|
|
|
suite->suite_init_err = 0;
|
2020-03-26 14:25:07 +00:00
|
|
|
}
|
|
|
|
|
2022-08-23 14:24:54 +00:00
|
|
|
bool kunit_enabled(void)
|
|
|
|
{
|
|
|
|
return enable_param;
|
|
|
|
}
|
|
|
|
|
2022-07-09 03:19:58 +00:00
|
|
|
int __kunit_test_suites_init(struct kunit_suite * const * const suites, int num_suites)
|
2020-03-26 14:25:07 +00:00
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
|
2022-08-23 14:24:54 +00:00
|
|
|
if (!kunit_enabled() && num_suites > 0) {
|
|
|
|
pr_info("kunit: disabled\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2022-11-25 08:43:04 +00:00
|
|
|
static_branch_inc(&kunit_running);
|
|
|
|
|
2022-07-09 03:19:58 +00:00
|
|
|
for (i = 0; i < num_suites; i++) {
|
2020-03-26 14:25:07 +00:00
|
|
|
kunit_init_suite(suites[i]);
|
|
|
|
kunit_run_tests(suites[i]);
|
|
|
|
}
|
2022-11-25 08:43:04 +00:00
|
|
|
|
|
|
|
static_branch_dec(&kunit_running);
|
2020-03-26 14:25:07 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(__kunit_test_suites_init);
|
|
|
|
|
|
|
|
static void kunit_exit_suite(struct kunit_suite *suite)
|
|
|
|
{
|
|
|
|
kunit_debugfs_destroy_suite(suite);
|
|
|
|
}
|
|
|
|
|
2022-07-09 03:19:58 +00:00
|
|
|
void __kunit_test_suites_exit(struct kunit_suite **suites, int num_suites)
|
2020-03-26 14:25:07 +00:00
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
|
2022-08-23 14:24:54 +00:00
|
|
|
if (!kunit_enabled())
|
|
|
|
return;
|
|
|
|
|
2022-07-09 03:19:58 +00:00
|
|
|
for (i = 0; i < num_suites; i++)
|
2020-03-26 14:25:07 +00:00
|
|
|
kunit_exit_suite(suites[i]);
|
kunit: Reset suite count after running tests
There are some KUnit tests (KFENCE, Thunderbolt) which, for various
reasons, do not use the kunit_test_suite() macro and end up running
before the KUnit executor runs its tests. This means that their results
are printed separately, and they aren't included in the suite count used
by the executor.
This causes the executor output to be invalid TAP, however, as the suite
numbers used are no-longer 1-based, and don't match the test plan.
kunit_tool, therefore, prints a large number of warnings.
While it'd be nice to fix the tests to run in the executor, in the
meantime, reset the suite counter to 1 in __kunit_test_suites_exit.
Not only does this fix the executor, it means that if there are multiple
calls to __kunit_test_suites_init() across different tests, they'll each
get their own numbering.
kunit_tool likes this better: even if it's lacking the results for those
tests which don't use the executor (due to the lack of TAP header), the
output for the other tests is valid.
Signed-off-by: David Gow <davidgow@google.com>
Reviewed-by: Daniel Latypov <dlatypov@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-10-06 04:41:11 +00:00
|
|
|
|
|
|
|
kunit_suite_counter = 1;
|
2020-03-26 14:25:07 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(__kunit_test_suites_exit);
|
|
|
|
|
2022-07-09 03:19:57 +00:00
|
|
|
#ifdef CONFIG_MODULES
|
|
|
|
static void kunit_module_init(struct module *mod)
|
|
|
|
{
|
kunit: Report the count of test suites in a module
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.
v3: Fix new name of a structure moved to kunit namespace not updated in
executor_test functions (lkp@intel.com).
v2: Use kunit_exec_run_tests() (Mauro, Rae), but prevent it from
emitting the headers when called on load of non-test modules.
[1] https://docs.kernel.org/dev-tools/ktap.html#
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Rae Moar <rmoar@google.com>
Reviewed-by: Rae Moar <rmoar@google.com>
Reviewed-by: David Gow <davidgow@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2023-08-07 10:23:54 +00:00
|
|
|
struct kunit_suite_set suite_set = {
|
|
|
|
mod->kunit_suites, mod->kunit_suites + mod->num_kunit_suites,
|
|
|
|
};
|
kunit: Make 'list' action available to kunit test modules
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" or "list_attr". For user convenience, make the
kunit.action parameter visible in sysfs.
v2: Don't use a different format, use kunit_exec_list_tests() (Rae),
- refresh on top of new attributes patches, handle newly introduced
kunit.action=list_attr case (Rae).
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: Rae Moar <rmoar@google.com>
Reviewed-by: David Gow <davidgow@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2023-08-07 10:23:55 +00:00
|
|
|
const char *action = kunit_action();
|
2023-08-07 10:23:56 +00:00
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
suite_set = kunit_filter_suites(&suite_set,
|
|
|
|
kunit_filter_glob() ?: "*.*",
|
|
|
|
kunit_filter(), kunit_filter_action(),
|
|
|
|
&err);
|
|
|
|
if (err)
|
|
|
|
pr_err("kunit module: error filtering suites: %d\n", err);
|
|
|
|
|
|
|
|
mod->kunit_suites = (struct kunit_suite **)suite_set.start;
|
|
|
|
mod->num_kunit_suites = suite_set.end - suite_set.start;
|
kunit: Make 'list' action available to kunit test modules
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" or "list_attr". For user convenience, make the
kunit.action parameter visible in sysfs.
v2: Don't use a different format, use kunit_exec_list_tests() (Rae),
- refresh on top of new attributes patches, handle newly introduced
kunit.action=list_attr case (Rae).
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: Rae Moar <rmoar@google.com>
Reviewed-by: David Gow <davidgow@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2023-08-07 10:23:55 +00:00
|
|
|
|
|
|
|
if (!action)
|
|
|
|
kunit_exec_run_tests(&suite_set, false);
|
|
|
|
else if (!strcmp(action, "list"))
|
|
|
|
kunit_exec_list_tests(&suite_set, false);
|
|
|
|
else if (!strcmp(action, "list_attr"))
|
|
|
|
kunit_exec_list_tests(&suite_set, true);
|
|
|
|
else
|
|
|
|
pr_err("kunit: unknown action '%s'\n", action);
|
2022-07-09 03:19:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void kunit_module_exit(struct module *mod)
|
|
|
|
{
|
2023-08-07 10:23:56 +00:00
|
|
|
struct kunit_suite_set suite_set = {
|
|
|
|
mod->kunit_suites, mod->kunit_suites + mod->num_kunit_suites,
|
|
|
|
};
|
kunit: Make 'list' action available to kunit test modules
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" or "list_attr". For user convenience, make the
kunit.action parameter visible in sysfs.
v2: Don't use a different format, use kunit_exec_list_tests() (Rae),
- refresh on top of new attributes patches, handle newly introduced
kunit.action=list_attr case (Rae).
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: Rae Moar <rmoar@google.com>
Reviewed-by: David Gow <davidgow@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2023-08-07 10:23:55 +00:00
|
|
|
const char *action = kunit_action();
|
|
|
|
|
|
|
|
if (!action)
|
|
|
|
__kunit_test_suites_exit(mod->kunit_suites,
|
|
|
|
mod->num_kunit_suites);
|
2023-08-07 10:23:56 +00:00
|
|
|
|
|
|
|
if (suite_set.start)
|
|
|
|
kunit_free_suite_set(suite_set);
|
2022-07-09 03:19:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int kunit_module_notify(struct notifier_block *nb, unsigned long val,
|
|
|
|
void *data)
|
|
|
|
{
|
|
|
|
struct module *mod = data;
|
|
|
|
|
|
|
|
switch (val) {
|
|
|
|
case MODULE_STATE_LIVE:
|
|
|
|
break;
|
|
|
|
case MODULE_STATE_GOING:
|
|
|
|
kunit_module_exit(mod);
|
|
|
|
break;
|
|
|
|
case MODULE_STATE_COMING:
|
kunit: Fix wild-memory-access bug in kunit_free_suite_set()
Inject fault while probing kunit-example-test.ko, if kstrdup()
fails in mod_sysfs_setup() in load_module(), the mod->state will
switch from MODULE_STATE_COMING to MODULE_STATE_GOING instead of
from MODULE_STATE_LIVE to MODULE_STATE_GOING, so only
kunit_module_exit() will be called without kunit_module_init(), and
the mod->kunit_suites is no set correctly and the free in
kunit_free_suite_set() will cause below wild-memory-access bug.
The mod->state state machine when load_module() succeeds:
MODULE_STATE_UNFORMED ---> MODULE_STATE_COMING ---> MODULE_STATE_LIVE
^ |
| | delete_module
+---------------- MODULE_STATE_GOING <---------+
The mod->state state machine when load_module() fails at
mod_sysfs_setup():
MODULE_STATE_UNFORMED ---> MODULE_STATE_COMING ---> MODULE_STATE_GOING
^ |
| |
+-----------------------------------------------+
Call kunit_module_init() at MODULE_STATE_COMING state to fix the issue
because MODULE_STATE_LIVE is transformed from it.
Unable to handle kernel paging request at virtual address ffffff341e942a88
KASAN: maybe wild-memory-access in range [0x0003f9a0f4a15440-0x0003f9a0f4a15447]
Mem abort info:
ESR = 0x0000000096000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x04: level 0 translation fault
Data abort info:
ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
CM = 0, WnR = 0, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000441ea000
[ffffff341e942a88] pgd=0000000000000000, p4d=0000000000000000
Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
Modules linked in: kunit_example_test(-) cfg80211 rfkill 8021q garp mrp stp llc ipv6 [last unloaded: kunit_example_test]
CPU: 3 PID: 2035 Comm: modprobe Tainted: G W N 6.5.0-next-20230828+ #136
Hardware name: linux,dummy-virt (DT)
pstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : kfree+0x2c/0x70
lr : kunit_free_suite_set+0xcc/0x13c
sp : ffff8000829b75b0
x29: ffff8000829b75b0 x28: ffff8000829b7b90 x27: 0000000000000000
x26: dfff800000000000 x25: ffffcd07c82a7280 x24: ffffcd07a50ab300
x23: ffffcd07a50ab2e8 x22: 1ffff00010536ec0 x21: dfff800000000000
x20: ffffcd07a50ab2f0 x19: ffffcd07a50ab2f0 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: ffffcd07c24b6764
x14: ffffcd07c24b63c0 x13: ffffcd07c4cebb94 x12: ffff700010536ec7
x11: 1ffff00010536ec6 x10: ffff700010536ec6 x9 : dfff800000000000
x8 : 00008fffefac913a x7 : 0000000041b58ab3 x6 : 0000000000000000
x5 : 1ffff00010536ec5 x4 : ffff8000829b7628 x3 : dfff800000000000
x2 : ffffff341e942a80 x1 : ffffcd07a50aa000 x0 : fffffc0000000000
Call trace:
kfree+0x2c/0x70
kunit_free_suite_set+0xcc/0x13c
kunit_module_notify+0xd8/0x360
blocking_notifier_call_chain+0xc4/0x128
load_module+0x382c/0x44a4
init_module_from_file+0xd4/0x128
idempotent_init_module+0x2c8/0x524
__arm64_sys_finit_module+0xac/0x100
invoke_syscall+0x6c/0x258
el0_svc_common.constprop.0+0x160/0x22c
do_el0_svc+0x44/0x5c
el0_svc+0x38/0x78
el0t_64_sync_handler+0x13c/0x158
el0t_64_sync+0x190/0x194
Code: aa0003e1 b25657e0 d34cfc42 8b021802 (f9400440)
---[ end trace 0000000000000000 ]---
Kernel panic - not syncing: Oops: Fatal exception
SMP: stopping secondary CPUs
Kernel Offset: 0x4d0742200000 from 0xffff800080000000
PHYS_OFFSET: 0xffffee43c0000000
CPU features: 0x88000203,3c020000,1000421b
Memory Limit: none
Rebooting in 1 seconds..
Fixes: 3d6e44623841 ("kunit: unify module and builtin suite definitions")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Reviewed-by: Rae Moar <rmoar@google.com>
Reviewed-by: David Gow <davidgow@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2023-09-03 07:10:25 +00:00
|
|
|
kunit_module_init(mod);
|
|
|
|
break;
|
2022-07-09 03:19:57 +00:00
|
|
|
case MODULE_STATE_UNFORMED:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct notifier_block kunit_mod_nb = {
|
|
|
|
.notifier_call = kunit_module_notify,
|
|
|
|
.priority = 0,
|
|
|
|
};
|
|
|
|
#endif
|
|
|
|
|
2023-05-25 04:21:30 +00:00
|
|
|
void *kunit_kmalloc_array(struct kunit *test, size_t n, size_t size, gfp_t gfp)
|
2019-09-23 09:02:32 +00:00
|
|
|
{
|
2023-05-25 04:21:30 +00:00
|
|
|
void *data;
|
2019-09-23 09:02:32 +00:00
|
|
|
|
2023-05-25 04:21:30 +00:00
|
|
|
data = kmalloc_array(n, size, gfp);
|
2019-09-23 09:02:32 +00:00
|
|
|
|
2023-05-25 04:21:30 +00:00
|
|
|
if (!data)
|
|
|
|
return NULL;
|
2019-09-23 09:02:32 +00:00
|
|
|
|
2023-05-25 04:21:30 +00:00
|
|
|
if (kunit_add_action_or_reset(test, (kunit_action_t *)kfree, data) != 0)
|
|
|
|
return NULL;
|
2019-09-23 09:02:32 +00:00
|
|
|
|
2023-05-25 04:21:30 +00:00
|
|
|
return data;
|
2019-09-23 09:02:32 +00:00
|
|
|
}
|
2021-05-03 20:58:34 +00:00
|
|
|
EXPORT_SYMBOL_GPL(kunit_kmalloc_array);
|
2019-09-23 09:02:32 +00:00
|
|
|
|
|
|
|
void kunit_kfree(struct kunit *test, const void *ptr)
|
|
|
|
{
|
2022-07-22 17:15:34 +00:00
|
|
|
if (!ptr)
|
|
|
|
return;
|
|
|
|
|
2023-05-25 04:21:30 +00:00
|
|
|
kunit_release_action(test, (kunit_action_t *)kfree, (void *)ptr);
|
2019-09-23 09:02:32 +00:00
|
|
|
}
|
2020-01-06 22:28:20 +00:00
|
|
|
EXPORT_SYMBOL_GPL(kunit_kfree);
|
2019-09-23 09:02:32 +00:00
|
|
|
|
|
|
|
void kunit_cleanup(struct kunit *test)
|
|
|
|
{
|
2020-05-29 21:46:20 +00:00
|
|
|
struct kunit_resource *res;
|
2021-06-29 02:34:30 +00:00
|
|
|
unsigned long flags;
|
2019-09-23 09:02:32 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* test->resources is a stack - each allocation must be freed in the
|
|
|
|
* reverse order from which it was added since one resource may depend
|
|
|
|
* on another for its entire lifetime.
|
|
|
|
* Also, we cannot use the normal list_for_each constructs, even the
|
|
|
|
* safe ones because *arbitrary* nodes may be deleted when
|
|
|
|
* kunit_resource_free is called; the list_for_each_safe variants only
|
|
|
|
* protect against the current node being deleted, not the next.
|
|
|
|
*/
|
|
|
|
while (true) {
|
2021-06-29 02:34:30 +00:00
|
|
|
spin_lock_irqsave(&test->lock, flags);
|
2019-09-23 09:02:32 +00:00
|
|
|
if (list_empty(&test->resources)) {
|
2021-06-29 02:34:30 +00:00
|
|
|
spin_unlock_irqrestore(&test->lock, flags);
|
2019-09-23 09:02:32 +00:00
|
|
|
break;
|
|
|
|
}
|
2020-05-29 21:46:20 +00:00
|
|
|
res = list_last_entry(&test->resources,
|
|
|
|
struct kunit_resource,
|
|
|
|
node);
|
|
|
|
/*
|
|
|
|
* Need to unlock here as a resource may remove another
|
|
|
|
* resource, and this can't happen if the test->lock
|
|
|
|
* is held.
|
|
|
|
*/
|
2021-06-29 02:34:30 +00:00
|
|
|
spin_unlock_irqrestore(&test->lock, flags);
|
2020-05-29 21:46:20 +00:00
|
|
|
kunit_remove_resource(test, res);
|
2019-09-23 09:02:32 +00:00
|
|
|
}
|
2020-10-13 23:55:02 +00:00
|
|
|
current->kunit_test = NULL;
|
2019-09-23 09:02:32 +00:00
|
|
|
}
|
2020-01-06 22:28:20 +00:00
|
|
|
EXPORT_SYMBOL_GPL(kunit_cleanup);
|
2020-01-06 22:28:22 +00:00
|
|
|
|
|
|
|
static int __init kunit_init(void)
|
|
|
|
{
|
kunit: Add "hooks" to call into KUnit when it's built as a module
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 <skhan@linuxfoundation.org>
Resolved merge conflicts with:
db105c37a4d6 ("kunit: Export kunit_running()")
This patch supersedes the above.
Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: David Gow <davidgow@google.com>
Reviewed-by: Rae Moar <rmoar@google.com>
Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2023-01-28 07:10:07 +00:00
|
|
|
/* Install the KUnit hook functions. */
|
|
|
|
kunit_install_hooks();
|
|
|
|
|
2020-03-26 14:25:07 +00:00
|
|
|
kunit_debugfs_init();
|
2022-07-09 03:19:57 +00:00
|
|
|
#ifdef CONFIG_MODULES
|
|
|
|
return register_module_notifier(&kunit_mod_nb);
|
|
|
|
#else
|
2020-01-06 22:28:22 +00:00
|
|
|
return 0;
|
2022-07-09 03:19:57 +00:00
|
|
|
#endif
|
2020-01-06 22:28:22 +00:00
|
|
|
}
|
|
|
|
late_initcall(kunit_init);
|
|
|
|
|
|
|
|
static void __exit kunit_exit(void)
|
|
|
|
{
|
kunit: Add "hooks" to call into KUnit when it's built as a module
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 <skhan@linuxfoundation.org>
Resolved merge conflicts with:
db105c37a4d6 ("kunit: Export kunit_running()")
This patch supersedes the above.
Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: David Gow <davidgow@google.com>
Reviewed-by: Rae Moar <rmoar@google.com>
Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2023-01-28 07:10:07 +00:00
|
|
|
memset(&kunit_hooks, 0, sizeof(kunit_hooks));
|
2022-07-09 03:19:57 +00:00
|
|
|
#ifdef CONFIG_MODULES
|
|
|
|
unregister_module_notifier(&kunit_mod_nb);
|
|
|
|
#endif
|
2020-03-26 14:25:07 +00:00
|
|
|
kunit_debugfs_cleanup();
|
2020-01-06 22:28:22 +00:00
|
|
|
}
|
|
|
|
module_exit(kunit_exit);
|
|
|
|
|
|
|
|
MODULE_LICENSE("GPL v2");
|