Message-ID: <CAKFsvU+N=8=VmKVdNdf6os26z+vVD=vR=TL5GJtLQhR9FxOJUQ@mail.gmail.com>
Date:   Tue, 24 Mar 2020 08:05:03 -0700
From:   Patricia Alfonso <trishalfonso@...gle.com>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     David Gow <davidgow@...gle.com>,
        Brendan Higgins <brendanhiggins@...gle.com>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        LKML <linux-kernel@...r.kernel.org>,
        kasan-dev <kasan-dev@...glegroups.com>,
        kunit-dev@...glegroups.com,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>
Subject: Re: [RFC PATCH v2 3/3] KASAN: Port KASAN Tests to KUnit

On Tue, Mar 24, 2020 at 4:25 AM Dmitry Vyukov <dvyukov@...gle.com> wrote:
>
> On Thu, Mar 19, 2020 at 5:42 PM 'Patricia Alfonso' via kasan-dev
> <kasan-dev@...glegroups.com> wrote:
> >
> > Transfer all previous tests for KASAN to KUnit so they can be run
> > more easily. Using kunit_tool, developers can run these tests with their
> > other KUnit tests and see "pass" or "fail" with the appropriate KASAN
> > report instead of needing to parse each KASAN report to test KASAN
> > functionalities. All KASAN reports are still printed to dmesg.
> >
> > Stack tests do not work in UML so those tests are protected inside an
> > "#if IS_ENABLED(CONFIG_KASAN_STACK)" so this only runs if stack
> > instrumentation is enabled.
> >
> > copy_user_test cannot be run in KUnit so there is a separate test file
> > for those tests, which can be run as before as a module.
>
> Hi Patricia,
>
> FWIW I've got some conflicts applying this patch on latest linux-next
> next-20200324. There are some changes to the tests in mm tree I think.
>
> Which tree will this go through? I would be nice to resolve these
> conflicts somehow, but I am not sure how. Maybe the kasan tests
> changes are merged upstream next windows, and then rebase this?
>
> Also, how can I apply this for testing? I assume this is based on some
> kunit branch? which one?
>
Hmm... okay, that sounds like a problem. I will have to look into the
conflicts. I'm not sure which tree this will go through upstream; I
expect someone will tell me which is best when the time comes. This is
based on the kunit branch in the kunit documentation here:
https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git/log/?h=kunit

> Why the copy_from_user tests can't be converted?
> It would be very nice to get rid of the modules entirely, rather than
> having 2 different test procedures because of 2 tests.
> Or, alternatively can there be other tests in future that can't be
> converted? Naming it "KASAN_USER" looks somewhat overspecialized. Say
> tomorrow we have another test that can't run under Kunit, but is not
> related to copt_from_user, should we create yet another module for it?
> I think the crux of that is that's a module, so a better name may be
> "KASAN_TEST_MODULE". Currently all tests that need to run as module
> are related to copy_from_user, but that's just an implementation
> detail.
>
When I converted the copy_user_tests into KUnit, I was getting a
kernel panic with a "Segfault with no mm." According to Brendan, since
KUnit starts a new kthread and is not invoked via a syscall, things
like copy_to_user won't work in the KUnit framework.

I agree that the naming is too specific, but is KASAN_TEST_MODULE too
generic since the current KASAN_TEST can be built as a module? Maybe
TEST_KASAN can be KUNIT_TEST_KASAN and TEST_KASAN_USER can be
TEST_KASAN_MODULE...

-- 
Best,
Patricia

Powered by blists - more mailing lists