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

From: Andrey Konovalov
Date: Tue Feb 09 2021 - 12:29:13 EST


On Tue, Feb 9, 2021 at 6:07 PM Catalin Marinas <catalin.marinas@xxxxxxx> wrote:
>
> On Tue, Feb 09, 2021 at 04:02:25PM +0100, Andrey Konovalov wrote:
> > On Tue, Feb 9, 2021 at 1:16 PM Vincenzo Frascino
> > <vincenzo.frascino@xxxxxxx> wrote:
> > > On 2/9/21 12:02 PM, Catalin Marinas wrote:
> > > > On Mon, Feb 08, 2021 at 04:56:17PM +0000, Vincenzo Frascino wrote:
> > > >> 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!