On Wed, Oct 19, 2022 at 10:58 AM 'David Gow' via kasan-dev kasan-dev@googlegroups.com wrote:
Enable the KASAN/KUnit integration even when the KASAN tests are disabled, as it's useful for testing other things under KASAN. Essentially, this reverts commit 49d9977ac909 ("kasan: check CONFIG_KASAN_KUNIT_TEST instead of CONFIG_KUNIT").
To mitigate the performance impact slightly, add a likely() to the check for a currently running test.
There's more we can do for performance if/when it becomes more of a problem, such as only enabling the "expect a KASAN failure" support wif the KASAN tests are enabled, or putting the whole thing behind a "kunit tests are running" static branch (which I do plan to do eventually).
Fixes: 49d9977ac909 ("kasan: check CONFIG_KASAN_KUNIT_TEST instead of CONFIG_KUNIT") Signed-off-by: David Gow davidgow@google.com
Basically, hiding the KASAN/KUnit integration broke being able to just pass --kconfig_add CONFIG_KASAN=y to kunit_tool to enable KASAN integration. We didn't notice this, because usually CONFIG_KUNIT_ALL_TESTS is enabled, which in turn enables CONFIG_KASAN_KUNIT_TEST. However, using a separate .kunitconfig might result in failures being missed.
Take, for example: ./tools/testing/kunit/kunit.py run --kconfig_add CONFIG_KASAN=y \ --kunitconfig drivers/gpu/drm/tests
This should run the drm tests with KASAN enabled, but even if there's a KASAN failure (such as the one fixed by [1]), kunit_tool will report success.
Hi David,
How does KUnit detect a KASAN failure for other tests than the KASAN ones? I thought this was only implemented for KASAN tests. At least, I don't see any code querying kunit_kasan_status outside of KASAN tests.
I'm currently switching KASAN tests from using KUnit resources to console tracepoints [1], and those patches will be in conflict with yours.
Thanks!
[1] https://lore.kernel.org/linux-mm/ebf96ea600050f00ed567e80505ae8f242633640.16...