path: root/lib/kunit/kunit-test.c
Commit message (Collapse)AuthorAgeFilesLines
* kunit: Make kunit_remove_resource() idempotentDavid Gow2022-04-051-0/+35
| | | | | | | | | | | | | | | | | | | | | | | | | The kunit_remove_resource() function is used to unlink a resource from the list of resources in the test, making it no longer show up in kunit_find_resource(). However, this could lead to a race condition if two threads called kunit_remove_resource() on the same resource at the same time: the resource would be removed from the list twice (causing a crash at the second list_del()), and the refcount for the resource would be decremented twice (instead of once, for the reference held by the resource list). Fix both problems, the first by using list_del_init(), and the second by checking if the resource has already been removed using list_empty(), and only decrementing its refcount if it has not. Also add a KUnit test for the kunit_remove_resource() function which tests this behaviour. Reported-by: Daniel Latypov <> Signed-off-by: David Gow <> Reviewed-by: Brendan Higgins <> Signed-off-by: Shuah Khan <>
* kunit: use NULL macrosRicardo Ribalda2022-04-041-1/+1
| | | | | | | | | Replace the NULL checks with the more specific and idiomatic NULL macros. Reviewed-by: Brendan Higgins <> Reviewed-by: Daniel Latypov <> Signed-off-by: Ricardo Ribalda <> Signed-off-by: Shuah Khan <>
* kunit: drop assumption in kunit-log-test about current suiteDaniel Latypov2021-10-191-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This test assumes that the declared kunit_suite object is the exact one which is being executed, which KUnit will not guarantee [1]. Specifically, `suite->log` is not initialized until a suite object is executed. So if KUnit makes a copy of the suite and runs that instead, this test dereferences an invalid pointer and (hopefully) segfaults. N.B. since we no longer assume this, we can no longer verify that `suite->log` is *not* allocated during normal execution. An alternative to this patch that would allow us to test that would require exposing an API for the current test to get its current suite. Exposing that for one internal kunit test seems like overkill, and grants users more footguns (e.g. reusing a test case in multiple suites and changing behavior based on the suite name, dynamically modifying the setup/cleanup funcs, storing/reading stuff out of the suite->log, etc.). [1] In a subsequent patch, KUnit will allow running subsets of test cases within a suite by making a copy of the suite w/ the filtered test list. But there are other reasons KUnit might execute a copy, e.g. if it ever wants to support parallel execution of different suites, recovering from errors and restarting suites Signed-off-by: Daniel Latypov <> Reviewed-by: Brendan Higgins <> Signed-off-by: Shuah Khan <>
* kunit: Support skipped testsDavid Gow2021-06-251-1/+41
| | | | | | | | | | | | | | | | | | | | | | | The kunit_mark_skipped() macro marks the current test as "skipped", with the provided reason. The kunit_skip() macro will mark the test as skipped, and abort the test. The TAP specification supports this "SKIP directive" as a comment after the "ok" / "not ok" for a test. See the "Directives" section of the TAP spec for details: The 'success' field for KUnit tests is replaced with a kunit_status enum, which can be SUCCESS, FAILURE, or SKIPPED, combined with a 'status_comment' containing information on why a test was skipped. A new 'kunit_status' test suite is added to test this. Signed-off-by: David Gow <> Tested-by: Marco Elver <> Reviewed-by: Daniel Latypov <> Reviewed-by: Brendan Higgins <> Signed-off-by: Shuah Khan <>
* kunit: add support for named resourcesAlan Maguire2020-06-261-0/+37
| | | | | | | | | | | | | | | | | | | | The kunit resources API allows for custom initialization and cleanup code (init/fini); here a new resource add function sets the "struct kunit_resource" "name" field, and calls the standard add function. Having a simple way to name resources is useful in cases such as multithreaded tests where a set of resources are shared among threads; a pointer to the "struct kunit *" test state then is all that is needed to retrieve and use named resources. Support is provided to add, find and destroy named resources; the latter two are simply wrappers that use a "match-by-name" callback. If an attempt to add a resource with a name that already exists is made kunit_add_named_resource() will return -EEXIST. Signed-off-by: Alan Maguire <> Reviewed-by: Brendan Higgins <> Signed-off-by: Shuah Khan <>
* kunit: generalize kunit_resource API beyond allocated resourcesAlan Maguire2020-06-261-20/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In its original form, the kunit resources API - consisting the struct kunit_resource and associated functions - was focused on adding allocated resources during test operation that would be automatically cleaned up on test completion. The recent RFC patch proposing converting KASAN tests to KUnit [1] showed another potential model - where outside of test context, but with a pointer to the test state, we wish to access/update test-related data, but expressly want to avoid allocations. It turns out we can generalize the kunit_resource to support static resources where the struct kunit_resource * is passed in and initialized for us. As part of this work, we also change the "allocation" field to the more general "data" name, as instead of associating an allocation, we can associate a pointer to static data. Static data is distinguished by a NULL free functions. A test is added to cover using kunit_add_resource() with a static resource and data. Finally we also make use of the kernel's krefcount interfaces to manage reference counting of KUnit resources. The motivation for this is simple; if we have kernel threads accessing and using resources (say via kunit_find_resource()) we need to ensure we do not remove said resources (or indeed free them if they were dynamically allocated) until the reference count reaches zero. A new function - kunit_put_resource() - is added to handle this, and it should be called after a thread using kunit_find_resource() is finished with the retrieved resource. We ensure that the functions needed to look up, use and drop reference count are "static inline"-defined so that they can be used by builtin code as well as modules in the case that KUnit is built as a module. A cosmetic change here also; I've tried moving to kunit_[action]_resource() as the format of function names for consistency and readability. [1] Signed-off-by: Alan Maguire <> Reviewed-by: Brendan Higgins <> Signed-off-by: Shuah Khan <>
* kunit: add log testAlan Maguire2020-03-261-1/+39
| | | | | | | | | | | the logging test ensures multiple strings logged appear in the log string associated with the test when CONFIG_KUNIT_DEBUGFS is enabled. Signed-off-by: Alan Maguire <> Reviewed-by: Brendan Higgins <> Reviewed-by: Frank Rowand <> Signed-off-by: Shuah Khan <>
* kunit: add debugfs /sys/kernel/debug/kunit/<suite>/results displayAlan Maguire2020-03-261-2/+2
| | | | | | | | | | | | | | add debugfs support for displaying kunit test suite results; this is especially useful for module-loaded tests to allow disentangling of test result display from other dmesg events. debugfs support is provided if CONFIG_KUNIT_DEBUGFS=y. As well as printk()ing messages, we append them to a per-test log. Signed-off-by: Alan Maguire <> Reviewed-by: Brendan Higgins <> Reviewed-by: Frank Rowand <> Signed-off-by: Shuah Khan <>
* kunit: allow kunit tests to be loaded as a moduleAlan Maguire2020-01-091-0/+334
As tests are added to kunit, it will become less feasible to execute all built tests together. By supporting modular tests we provide a simple way to do selective execution on a running system; specifying CONFIG_KUNIT=y CONFIG_KUNIT_EXAMPLE_TEST=m ...means we can simply "insmod example-test.ko" to run the tests. To achieve this we need to do the following: o export the required symbols in kunit o string-stream tests utilize non-exported symbols so for now we skip building them when CONFIG_KUNIT_TEST=m. o drivers/base/power/qos-test.c contains a few unexported interface references, namely freq_qos_read_value() and freq_constraints_init(). Both of these could be potentially defined as static inline functions in include/linux/pm_qos.h, but for now we simply avoid supporting module build for that test suite. o support a new way of declaring test suites. Because a module cannot do multiple late_initcall()s, we provide a kunit_test_suites() macro to declare multiple suites within the same module at once. o some test module names would have been too general ("test-test" and "example-test" for kunit tests, "inode-test" for ext4 tests); rename these as appropriate ("kunit-test", "kunit-example-test" and "ext4-inode-test" respectively). Also define kunit_test_suite() via kunit_test_suites() as callers in other trees may need the old definition. Co-developed-by: Knut Omang <> Signed-off-by: Knut Omang <> Signed-off-by: Alan Maguire <> Reviewed-by: Brendan Higgins <> Acked-by: Theodore Ts'o <> # for ext4 bits Acked-by: David Gow <> # For list-test Reported-by: kbuild test robot <> Signed-off-by: Shuah Khan <>