Thread (28 messages) 28 messages, 6 authors, 2021-02-10

Re: [PATCH v12 7/7] kasan: don't run tests in async mode

From: Andrey Konovalov <hidden>
Date: 2021-02-09 17:29:07
Also in: lkml

On Tue, Feb 9, 2021 at 6:07 PM Catalin Marinas [off-list ref] wrote:
On Tue, Feb 09, 2021 at 04:02:25PM +0100, Andrey Konovalov wrote:
quoted
On Tue, Feb 9, 2021 at 1:16 PM Vincenzo Frascino
[off-list ref] wrote:
quoted
On 2/9/21 12:02 PM, Catalin Marinas wrote:
quoted
On Mon, Feb 08, 2021 at 04:56:17PM +0000, Vincenzo Frascino wrote:
quoted
diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index 7285dcf9fcc1..f82d9630cae1 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -51,6 +51,10 @@ static int kasan_test_init(struct kunit *test)
             kunit_err(test, "can't run KASAN tests with KASAN disabled");
             return -1;
     }
+    if (kasan_flag_async) {
+            kunit_err(test, "can't run KASAN tests in async mode");
+            return -1;
+    }

     multishot = kasan_save_enable_multi_shot();
     hw_set_tagging_report_once(false);
I think we can still run the kasan tests in async mode if we check the
TFSR_EL1 at the end of each test by calling mte_check_tfsr_exit().
IIUC this was the plan for the future. But I let Andrey comment for more details.
If it's possible to implement, then it would be good to have. Doesn't
have to be a part of this series though.
I think it can be part of this series but after the 5.12 merging window
(we are a few days away from final 5.11 and I don't think we should
rush the MTE kernel async support in).

It would be nice to have the kasan tests running with async by the time
we merge the patches (at a quick look, I think it's possible but, of
course, we may hit some blockers when implementing it).
OK, sounds good.

If it's possible to put an explicit check for tag faults at the end of
each test, then adding async support shouldn't be hard.

Note, that some of the tests trigger bugs that are detected via
explicit checks within KASAN. For example, KASAN checks that a pointer
that's being freed points to a start of a slab object, or that the
object is accessible when it gets freed, etc. I don't see this being a
problem, so just FYI.

Thanks!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help