kernel/linux.git/lib/kunit/Kconfig, branch v6.19.11

kunit: make FAULT_TEST default to n when PANIC_ON_OOPS

2025-12-15T16:27:19+00:00

As describe in the help string, the user might want to disable these tests if they don't like to see stacktraces/BUG etc in their kernel log. However, if they enable PANIC_ON_OOPS, these tests also crash the machine, which it's safe to assume _almost_ nobody wants. One might argue that _absolutely_ nobody ever wants their kernel to crash so this should just be a hard dependency instead of a default. However, since this is rather special code that's anyway concerned with deliberately doing "bad" things, the normal rules don't seem to apply, hence prefer flexibility and allow users to set up a crashing Kconfig if they so choose. Link: https://lore.kernel.org/r/20251207-kunit-fault-no-panic-v1-1-2ac932f26864@google.com Signed-off-by: Brendan Jackman Reviewed-by: David Gow Signed-off-by: Shuah Khan

kunit: Make filter parameters configurable via Kconfig

2025-11-14T18:02:34+00:00

Enable the preset of filter parameters from kconfig options, similar to how other KUnit configuration parameters are handled already. This is useful to run a subset of tests even if the cmdline is not readily modifyable. Link: https://lore.kernel.org/r/20251106-kunit-filter-kconfig-v1-1-d723fb7ac221@linutronix.de Signed-off-by: Thomas Weißschuh Reviewed-by: David Gow Signed-off-by: Shuah Khan

kunit: Extend kconfig help text for KUNIT_UML_PCI

2025-09-16T14:27:09+00:00

Checkpatch.pl expects at least 4 lines of help text. Extend the help text to make checkpatch.pl happy. Link: https://lore.kernel.org/r/20250916-kunit-pci-kconfig-v1-1-6d1369f06f2a@linutronix.de Fixes: 031cdd3bc3f3 ("kunit: Enable PCI on UML without triggering WARN()") Suggested-by: Shuah Khan Link: https://lore.kernel.org/lkml/3dc95227-2be9-48a0-bdea-3f283d9b2a38@linuxfoundation.org/ Signed-off-by: Thomas Weißschuh Reviewed-by: David Gow Signed-off-by: Shuah Khan

kunit: Enable PCI on UML without triggering WARN()

2025-09-15T16:29:59+00:00

Various KUnit tests require PCI infrastructure to work. All normal platforms enable PCI by default, but UML does not. Enabling PCI from .kunitconfig files is problematic as it would not be portable. So in commit 6fc3a8636a7b ("kunit: tool: Enable virtio/PCI by default on UML") PCI was enabled by way of CONFIG_UML_PCI_OVER_VIRTIO=y. However CONFIG_UML_PCI_OVER_VIRTIO requires additional configuration of CONFIG_UML_PCI_OVER_VIRTIO_DEVICE_ID or will otherwise trigger a WARN() in virtio_pcidev_init(). However there is no one correct value for UML_PCI_OVER_VIRTIO_DEVICE_ID which could be used by default. This warning is confusing when debugging test failures. On the other hand, the functionality of CONFIG_UML_PCI_OVER_VIRTIO is not used at all, given that it is completely non-functional as indicated by the WARN() in question. Instead it is only used as a way to enable CONFIG_UML_PCI which itself is not directly configurable. Instead of going through CONFIG_UML_PCI_OVER_VIRTIO, introduce a custom configuration option which enables CONFIG_UML_PCI without triggering warnings or building dead code. Link: https://lore.kernel.org/r/20250908-kunit-uml-pci-v2-1-d8eba5f73c9d@linutronix.de Signed-off-by: Thomas Weißschuh Reviewed-by: Johannes Berg Reviewed-by: David Gow Signed-off-by: Shuah Khan

kunit: Make default kunit_test timeout configurable via both a module parameter and a Kconfig option

2025-06-27T21:00:05+00:00

To accommodate varying hardware performance and use cases, the default kunit test case timeout (currently 300 seconds) is now configurable. Users can adjust the timeout by either setting the 'timeout' module parameter or the KUNIT_DEFAULT_TIMEOUT Kconfig option to their desired timeout in seconds. Link: https://lore.kernel.org/r/20250626171730.1765004-1-marievic@google.com Signed-off-by: Marie Zhussupova Reviewed-by: David Gow Signed-off-by: Shuah Khan

kunit: Introduce autorun option

2025-01-15T16:04:06+00:00

The new option controls tests run on boot or module load. With the new debugfs "run" dentry allowing to run tests on demand, an ability to disable automatic tests run becomes a useful option in case of intrusive tests. The option is set to true by default to preserve the existent behavior. It can be overridden by either the corresponding module option or by the corresponding config build option. Link: https://lore.kernel.org/r/173015245931.4747.16419517391658830640.stgit@skinsburskii-cloud-desktop.internal.cloudapp.net Signed-off-by: Stanislav Kinsburskii Reviewed-by: Rae Moar Acked-by: David Gow Signed-off-by: Shuah Khan

kunit: test: Move fault tests behind KUNIT_FAULT_TEST Kconfig option

2024-05-06T20:22:02+00:00

The NULL dereference tests in kunit_fault deliberately trigger a kernel BUG(), and therefore print the associated stack trace, even when the test passes. This is both annoying (as it bloats the test output), and can confuse some test harnesses, which assume any BUG() is a failure. Allow these tests to be specifically disabled (without disabling all of KUnit's other tests), by placing them behind the CONFIG_KUNIT_FAULT_TEST Kconfig option. This is enabled by default, but can be set to 'n' to disable the test. An empty 'kunit_fault' suite is left behind, which will automatically be marked 'skipped'. As the fault tests already were disabled under UML (as they weren't compatible with its fault handling), we can simply adapt those conditions, and add a dependency on !UML for our new option. Suggested-by: Guenter Roeck Link: https://lore.kernel.org/all/928249cc-e027-4f7f-b43f-502f99a1ea63@roeck-us.net/ Fixes: 82b0beff3497 ("kunit: Add tests for fault") Signed-off-by: David Gow Reviewed-by: Mickaël Salaün Reviewed-by: Rae Moar Signed-off-by: Shuah Khan

kunit: Allow kunit test modules to use test filtering

2023-08-08T19:46:18+00:00

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 Reviewed-by: David Gow Signed-off-by: Shuah Khan

kunit: add kunit.enable to enable/disable KUnit test

2022-09-30T19:17:39+00:00

This patch adds the kunit.enable module parameter that will need to be set to true in addition to KUNIT being enabled for KUnit tests to run. The default value is true giving backwards compatibility. However, for the production+testing use case the new config option KUNIT_DEFAULT_ENABLED can be set to N requiring the tester to opt-in by passing kunit.enable=1 to the kernel. Signed-off-by: Joe Fradley Reviewed-by: David Gow Signed-off-by: Shuah Khan

kunit: add kunit.filter_glob cmdline option to filter suites

2021-02-08T23:09:27+00:00

E.g. specifying this would run suites with "list" in their name. kunit.filter_glob=list* Note: the executor prints out a TAP header that includes the number of suites we intend to run. So unless we want to report empty results for filtered-out suites, we need to do the filtering here in the executor. It's also probably better in the executor since we most likely don't want any filtering to apply to tests built as modules. This code does add a CONFIG_GLOB=y dependency for CONFIG_KUNIT=y. But the code seems light enough that it shouldn't be an issue. For now, we only filter on suite names so we don't have to create copies of the suites themselves, just the array (of arrays) holding them. The name is rather generic since in the future, we could consider extending it to a syntax like: kunit.filter_glob=. E.g. to run all the del list tests kunit.filter_glob=list-kunit-test.*del* But at the moment, it's far easier to manually comment out test cases in test files as opposed to messing with sets of Kconfig entries to select specific suites. So even just doing this makes using kunit far less annoying. Signed-off-by: Daniel Latypov Reviewed-by: Brendan Higgins Signed-off-by: Shuah Khan