8bd5d74b | 08-Apr-2024 |
Mickaël Salaün <mic@digikod.net> |
kunit: Print last test location on fault
This helps identify the location of test faults with opportunistic calls to _KUNIT_SAVE_LOC(). This can be useful while writing tests or debugging them. It
kunit: Print last test location on fault
This helps identify the location of test faults with opportunistic calls to _KUNIT_SAVE_LOC(). This can be useful while writing tests or debugging them. It is possible to call KUNIT_SUCCESS() to explicit save last location.
Cc: Brendan Higgins <brendanhiggins@google.com> Cc: David Gow <davidgow@google.com> Cc: Rae Moar <rmoar@google.com> Cc: Shuah Khan <skhan@linuxfoundation.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Mickaël Salaün <mic@digikod.net> Link: https://lore.kernel.org/r/20240408074625.65017-7-mic@digikod.net Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
show more ...
|
7ece381a | 20-Dec-2023 |
Richard Fitzgerald <rf@opensource.cirrus.com> |
kunit: Protect string comparisons against NULL
Add NULL checks to KUNIT_BINARY_STR_ASSERTION() so that it will fail cleanly if either pointer is NULL, instead of causing a NULL pointer dereference i
kunit: Protect string comparisons against NULL
Add NULL checks to KUNIT_BINARY_STR_ASSERTION() so that it will fail cleanly if either pointer is NULL, instead of causing a NULL pointer dereference in the strcmp().
A test failure could be that a string is unexpectedly NULL. This could be trapped by KUNIT_ASSERT_NOT_NULL() but that would terminate the test at that point. It's preferable that the KUNIT_EXPECT_STR*() macros can handle NULL pointers as a failure.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Reviewed-by: David Gow <davidgow@google.com> Reviewed-by: Muhammad Usama Anjum <usama.anjum@collabora.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
show more ...
|
fcbac39b | 21-Dec-2023 |
Richard Fitzgerald <rf@opensource.cirrus.com> |
kunit: Allow passing function pointer to kunit_activate_static_stub()
Swap the arguments to typecheck_fn() in kunit_activate_static_stub() so that real_fn_addr can be either the function itself or a
kunit: Allow passing function pointer to kunit_activate_static_stub()
Swap the arguments to typecheck_fn() in kunit_activate_static_stub() so that real_fn_addr can be either the function itself or a pointer to that function.
This is useful to simplify redirecting static functions in a module. Having to pass the actual function meant that it must be exported from the module. Either making the 'static' and EXPORT_SYMBOL*() conditional (which makes the code messy), or change it to always exported (which increases the export namespace and prevents the compiler inlining a trivial stub function in non-test builds).
With the original definition of kunit_activate_static_stub() the address of real_fn_addr was passed to typecheck_fn() as the type to be passed. This meant that if real_fn_addr was a pointer-to-function it would resolve to a ** instead of a *, giving an error like this:
error: initialization of ‘int (**)(int)’ from incompatible pointer type ‘int (*)(int)’ [-Werror=incompatible-pointer-types] kunit_activate_static_stub(test, add_one_fn_ptr, subtract_one); | ^~~~~~~~~~~~ ./include/linux/typecheck.h:21:25: note: in definition of macro ‘typecheck_fn’ 21 | ({ typeof(type) __tmp = function; \
Swapping the arguments to typecheck_fn makes it take the type of a pointer to the replacement function. Either a function or a pointer to function can be assigned to that. For example:
static int some_function(int x) { /* whatever */ }
int (* some_function_ptr)(int) = some_function;
static int replacement(int x) { /* whatever */ }
Then: kunit_activate_static_stub(test, some_function, replacement); yields: typecheck_fn(typeof(&replacement), some_function);
and: kunit_activate_static_stub(test, some_function_ptr, replacement); yields: typecheck_fn(typeof(&replacement), some_function_ptr);
The two typecheck_fn() then resolve to:
int (*__tmp)(int) = some_function; and int (*__tmp)(int) = some_function_ptr;
Both of these are valid. In the first case the compiler inserts an implicit '&' to take the address of the supplied function, and in the second case the RHS is already a pointer to the same type.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Reviewed-by: Rae Moar <rmoar@google.com> Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
show more ...
|
b3231d35 | 20-Dec-2023 |
Benjamin Berg <benjamin.berg@intel.com> |
kunit: add a convenience allocation wrapper for SKBs
Add a simple convenience helper to allocate and zero fill an SKB for the use by a kunit test. Also provide a way to free it again in case that ma
kunit: add a convenience allocation wrapper for SKBs
Add a simple convenience helper to allocate and zero fill an SKB for the use by a kunit test. Also provide a way to free it again in case that may be desirable.
This simply mirrors the kunit_kmalloc API.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Reviewed-by: David Gow <davidgow@google.com> Link: https://msgid.link/20231220151952.415232-3-benjamin@sipsolutions.net [adjust file description as discussed] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
d03c720e | 15-Dec-2023 |
davidgow@google.com <davidgow@google.com> |
kunit: Add APIs for managing devices
Tests for drivers often require a struct device to pass to other functions. While it's possible to create these with root_device_register(), or to use something
kunit: Add APIs for managing devices
Tests for drivers often require a struct device to pass to other functions. While it's possible to create these with root_device_register(), or to use something like a platform device, this is both a misuse of those APIs, and can be difficult to clean up after, for example, a failed assertion.
Add some KUnit-specific functions for registering and unregistering a struct device: - kunit_device_register() - kunit_device_register_with_driver() - kunit_device_unregister()
These helpers allocate a on a 'kunit' bus which will either probe the driver passed in (kunit_device_register_with_driver), or will create a stub driver (kunit_device_register) which is cleaned up on test shutdown.
Devices are automatically unregistered on test shutdown, but can be manually unregistered earlier with kunit_device_unregister() in order to, for example, test device release code.
Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: David Gow <davidgow@google.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
show more ...
|
6c4ea2f4 | 13-Dec-2023 |
Rae Moar <rmoar@google.com> |
kunit: add is_init test attribute
Add is_init test attribute of type bool. Add to_string, get, and filter methods to lib/kunit/attributes.c.
Mark each of the tests in the init section with the is_i
kunit: add is_init test attribute
Add is_init test attribute of type bool. Add to_string, get, and filter methods to lib/kunit/attributes.c.
Mark each of the tests in the init section with the is_init=true attribute.
Add is_init to the attributes documentation.
Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Rae Moar <rmoar@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
show more ...
|
582eb3ae | 25-Jul-2023 |
Kemeng Shi <shikemeng@huaweicloud.com> |
kunit: replace KUNIT_TRIGGER_STATIC_STUB maro with KUNIT_STATIC_STUB_REDIRECT
We mix up KUNIT_TRIGGER_STATIC_STUB and KUNIT_STATIC_STUB_REDIRECT in static_stub header. Just correct KUNIT_TRIGGER_STA
kunit: replace KUNIT_TRIGGER_STATIC_STUB maro with KUNIT_STATIC_STUB_REDIRECT
We mix up KUNIT_TRIGGER_STATIC_STUB and KUNIT_STATIC_STUB_REDIRECT in static_stub header. Just correct KUNIT_TRIGGER_STATIC_STUB to KUNIT_STATIC_STUB_REDIRECT which is documented.
Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com> Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
show more ...
|
b67abaad | 07-Aug-2023 |
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> |
kunit: Allow kunit test modules to use test filtering
External tools, e.g., Intel GPU tools (IGT), support execution of individual selftests provided by kernel modules. That could be also applicabl
kunit: Allow kunit test modules to use test filtering
External tools, e.g., Intel GPU tools (IGT), support execution of individual selftests provided by kernel modules. That could be also applicable to kunit test modules if they provided test filtering. But test filtering is now possible only when kunit code is built into the kernel. Moreover, a filter can be specified only at boot time, then reboot is required each time a different filter is needed.
Build the test filtering code also when kunit is configured as a module, expose test filtering functions to other kunit source files, and use them in kunit module notifier callback functions. Userspace can then reload the kunit module with a value of the filter_glob parameter tuned to a specific kunit test module every time it wants to limit the scope of tests executed on that module load. Make the kunit.filter* parameters visible in sysfs for user convenience.
v5: Refresh on tpp of attributes filtering fix v4: Refresh on top of newly applied attributes patches and changes introdced by new versions of other patches submitted in series with this one. v3: Fix CONFIG_GLOB, required by filtering functions, not selected when building as a module (lkp@intel.com). v2: Fix new name of a structure moved to kunit namespace not updated across all uses (lkp@intel.com).
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
show more ...
|
18258c60 | 07-Aug-2023 |
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> |
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
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>
show more ...
|
c95e7c05 | 07-Aug-2023 |
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> |
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
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>
show more ...
|
529534e8 | 25-Jul-2023 |
Rae Moar <rmoar@google.com> |
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><operatio
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>
show more ...
|
a00a7270 | 25-Jul-2023 |
Rae Moar <rmoar@google.com> |
kunit: Add module attribute
Add module attribute to the test attribute API. This attribute stores the module name associated with the test using KBUILD_MODNAME.
The name of a test suite and the mod
kunit: Add module attribute
Add module attribute to the test attribute API. This attribute stores the module name associated with the test using KBUILD_MODNAME.
The name of a test suite and the module name often do not match. A reference to the module name associated with the suite could be extremely helpful in running tests as modules without needing to check the codebase.
This attribute will be printed for each suite.
Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Rae Moar <rmoar@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
show more ...
|
02c2d0c2 | 25-Jul-2023 |
Rae Moar <rmoar@google.com> |
kunit: Add speed attribute
Add speed attribute to the test attribute API. This attribute will allow users to mark tests with a category of speed.
Currently the categories of speed proposed are: nor
kunit: Add speed attribute
Add speed attribute to the test attribute API. This attribute will allow users to mark tests with a category of speed.
Currently the categories of speed proposed are: normal, slow, and very_slow (outlined in enum kunit_speed). These are outlined in the enum kunit_speed.
The assumed default speed for tests is "normal". This indicates that the test takes a relatively trivial amount of time (less than 1 second), regardless of the machine it is running on. Any test slower than this could be marked as "slow" or "very_slow".
Add the macro KUNIT_CASE_SLOW to set a test as slow, as this is likely a common use of the attributes API.
Add an example of marking a slow test to kunit-example-test.c.
Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Rae Moar <rmoar@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
show more ...
|
39e92cb1 | 25-Jul-2023 |
Rae Moar <rmoar@google.com> |
kunit: Add test attributes API structure
Add the basic structure of the test attribute API to KUnit, which can be used to save and access test associated data.
Add attributes.c and attributes.h to
kunit: Add test attributes API structure
Add the basic structure of the test attribute API to KUnit, which can be used to save and access test associated data.
Add attributes.c and attributes.h to hold associated structs and functions for the API.
Create a struct that holds a variety of associated helper functions for each test attribute. These helper functions will be used to get the attribute value, convert the value to a string, and filter based on the value. This struct is flexible by design to allow for attributes of numerous types and contexts.
Add a method to print test attributes in the format of "# [<test_name if not suite>.]<attribute_name>: <attribute_value>".
Example for a suite: "# speed: slow"
Example for a test case: "# test_case.speed: very_slow"
Use this method to report attributes in the KTAP output (KTAP spec: https://docs.kernel.org/dev-tools/ktap.html) and _list_tests output when kernel's new kunit.action=list_attr option is used. Note this is derivative of the kunit.action=list option.
In test.h, add fields and associated helper functions to test cases and suites to hold user-inputted test attributes.
Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Rae Moar <rmoar@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
show more ...
|
26075518 | 31-May-2023 |
David Gow <davidgow@google.com> |
kunit: Move kunit_abort() call out of kunit_do_failed_assertion()
KUnit aborts the current thread when an assertion fails. Currently, this is done conditionally as part of the kunit_do_failed_assert
kunit: Move kunit_abort() call out of kunit_do_failed_assertion()
KUnit aborts the current thread when an assertion fails. Currently, this is done conditionally as part of the kunit_do_failed_assertion() function, but this hides the kunit_abort() call from the compiler (particularly if it's in another module). This, in turn, can lead to both suboptimal code generation (the compiler can't know if kunit_do_failed_assertion() will return), and to static analysis tools like smatch giving false positives.
Moving the kunit_abort() call into the macro should give the compiler and tools a better chance at understanding what's going on. Doing so requires exporting kunit_abort(), though it's recommended to continue to use assertions in lieu of aborting directly.
In addition, kunit_abort() and kunit_do_failed_assertion() are renamed to make it clear they they're intended for internal KUnit use, to: __kunit_do_failed_assertion() and __kunit_abort()
Suggested-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: David Gow <davidgow@google.com> Reviewed-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Daniel Latypov <dlatypov@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
show more ...
|