On Wed, Oct 19, 2022 at 10:18 PM Andrey Konovalov andreyknvl@gmail.com wrote:
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.
Yeah, there aren't any other tests which set up a "kasan_status" resource to expect specific failures, but we still want the fallback call to kunit_set_failure() so that any test which causes a KASAN report will fail: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/k...
I'm currently switching KASAN tests from using KUnit resources to console tracepoints [1], and those patches will be in conflict with yours.
Ah, sorry -- I'd seen these go past, and totally forgot about them! I think all we really want to keep is the ability to fail tests if a KASAN report occurs. The tricky bit is then disabling that for the KASAN tests, so that they can have "expected" failures.
-- David