From: Brendan Higgins <brendanhiggins@google.com>
To: Alan Maguire <alan.maguire@oracle.com>
Cc: Patricia Alfonso <trishalfonso@google.com>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Dmitry Vyukov <dvyukov@google.com>,
David Gow <davidgow@google.com>, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
kasan-dev <kasan-dev@googlegroups.com>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
KUnit Development <kunit-dev@googlegroups.com>
Subject: Re: [RFC PATCH 2/2] KUnit: KASAN Integration
Date: Tue, 10 Mar 2020 14:39:16 -0700 [thread overview]
Message-ID: <CAFd5g44gVFyxwo4r=7gpPGdvPQoynfEjHhLfyC3_6uaU2oA0Lg@mail.gmail.com> (raw)
In-Reply-To: <alpine.LRH.2.20.2002271136160.12417@dhcp-10-175-190-15.vpn.oracle.com>
On Thu, Feb 27, 2020 at 6:04 AM Alan Maguire <alan.maguire@oracle.com> wrote:
Sorry for the delay in reviews. I have been preoccupied by some Google
internal stuff.
> On Wed, 26 Feb 2020, Patricia Alfonso wrote:
>
> > Integrate KASAN into KUnit testing framework.
>
> This is a great idea! Some comments/suggestions below...
>
> > - Fail tests when KASAN reports an error that is not expected
> > - Use KUNIT_EXPECT_KASAN_FAIL to expect a KASAN error in KASAN tests
> > - KUnit struct added to current task to keep track of the current test
> > from KASAN code
> > - Booleans representing if a KASAN report is expected and if a KASAN
> > report is found added to kunit struct
> > - This prints "line# has passed" or "line# has failed"
> >
> > Signed-off-by: Patricia Alfonso <trishalfonso@google.com>
> > ---
> > If anyone has any suggestions on how best to print the failure
> > messages, please share!
> >
> > One issue I have found while testing this is the allocation fails in
> > kmalloc_pagealloc_oob_right() sometimes, but not consistently. This
> > does cause the test to fail on the KUnit side, as expected, but it
> > seems to skip all the tests before this one because the output starts
> > with this failure instead of with the first test, kmalloc_oob_right().
> >
> > include/kunit/test.h | 24 ++++++++++++++++++++++++
> > include/linux/sched.h | 7 ++++++-
> > lib/kunit/test.c | 7 ++++++-
> > mm/kasan/report.c | 19 +++++++++++++++++++
> > tools/testing/kunit/kunit_kernel.py | 2 +-
> > 5 files changed, 56 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/kunit/test.h b/include/kunit/test.h
> > index 2dfb550c6723..2e388f8937f3 100644
> > --- a/include/kunit/test.h
> > +++ b/include/kunit/test.h
> > @@ -21,6 +21,8 @@ struct kunit_resource;
> > typedef int (*kunit_resource_init_t)(struct kunit_resource *, void *);
> > typedef void (*kunit_resource_free_t)(struct kunit_resource *);
> >
> > +void kunit_set_failure(struct kunit *test);
> > +
> > /**
> > * struct kunit_resource - represents a *test managed resource*
> > * @allocation: for the user to store arbitrary data.
> > @@ -191,6 +193,9 @@ struct kunit {
> > * protect it with some type of lock.
> > */
> > struct list_head resources; /* Protected by lock. */
> > +
> > + bool kasan_report_expected;
> > + bool kasan_report_found;
> > };
> >
>
> Is this needed here? You're testing something pretty
> specific so it seems wrong to add to the generic
> kunit resource unless there's a good reason. I see the
> code around setting these values in mm/kasan/report.c,
> but I wonder if we could do something more generic.
>
> How about the concept of a static resource (assuming a
> dynamically allocated one is out because it messes
> with memory allocation tests)? Something like this:
>
> #define kunit_add_static_resource(test, resource_ptr, resource_field) \
> do { \
> spin_lock(&test->lock); \
> (resource_ptr)->resource_field.init = NULL; \
> (resource_ptr)->resource_field.free = NULL; \
> list_add_tail(&(resource_ptr)->resource_field, \
> &test->resources); \
> spin_unlock(&test->lock); \
> } while (0)
>
>
> Within your kasan code you could then create a kasan-specific
> structure that embends a kunit_resource, and contains the
> values you need:
>
> struct kasan_report_resource {
> struct kunit_resource res;
> bool kasan_report_expected;
> bool kasan_report_found;
> };
>
> (One thing we'd need to do for such static resources is fix
> kunit_resource_free() to check if there's a free() function,
> and if not assume a static resource)
>
> If you then create an init() function associated with your
> kunit suite (which will be run for every case) it can do this:
>
> int kunit_kasan_test_init(struct kunit *test)
> {
> kunit_add_static_resource(test, &my_kasan_report_resource, res);
> ...
> }
>
> The above should also be used to initialize current->kasan_unit_test
> instead of doing that in kunit_try_run_case(). With those
> changes, you don't (I think) need to change anything in core
> kunit (assuming support for static resources).
>
> To retrieve the resource during tests or in kasan context, the
> method seems to be to use kunit_resource_find(). However, that
> requires a match function which seems a bit heavyweight for the
> static case. We should probably have a default "find by name"
> or similar function here, and add an optional "name" field
> to kunit resources to simplify things. Anyway here you'd
> use something like:
>
> kasan_report_resource = kunit_resource_find(test, matchfn,
> NULL, matchdata);
>
>
> Are there any barriers to taking this sort of approach (apart
> from the support for static resources not being there yet)?
This is a really interesting idea, Alan! I never imagined
kunit_resources being used this way, and I like it. I saw you sent
some patches to implement this stuff, so I will withhold further
comments on that here.
next prev parent reply other threads:[~2020-03-10 21:39 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-27 2:43 [RFC PATCH 1/2] Port KASAN Tests to KUnit Patricia Alfonso
2020-02-27 2:43 ` [RFC PATCH 2/2] KUnit: KASAN Integration Patricia Alfonso
2020-02-27 14:04 ` Alan Maguire
2020-02-29 0:46 ` Patricia Alfonso
2020-03-03 16:40 ` Alan Maguire
2020-03-05 2:14 ` Patricia Alfonso
2020-03-05 7:46 ` Alan Maguire
2020-03-10 21:42 ` Brendan Higgins
2020-03-10 21:42 ` Brendan Higgins
2020-03-10 21:39 ` Brendan Higgins [this message]
2020-03-10 21:39 ` Brendan Higgins
2020-02-27 14:39 ` Dmitry Vyukov
2020-02-29 1:09 ` Patricia Alfonso
2020-03-01 6:26 ` Dmitry Vyukov
2020-02-27 14:43 ` Dmitry Vyukov
2020-02-29 1:23 ` Patricia Alfonso
2020-03-01 6:29 ` Dmitry Vyukov
2020-03-04 1:26 ` Patricia Alfonso
2020-03-04 6:23 ` Dmitry Vyukov
2020-03-05 0:07 ` Patricia Alfonso
2020-03-05 6:44 ` Dmitry Vyukov
2020-02-27 14:45 ` Dmitry Vyukov
2020-02-29 0:49 ` Patricia Alfonso
2020-03-04 6:35 ` Dmitry Vyukov
2020-02-27 13:56 ` [RFC PATCH 1/2] Port KASAN Tests to KUnit Andrey Konovalov
2020-02-27 15:16 ` Alan Maguire
2020-02-27 14:19 ` Dmitry Vyukov
2020-02-29 1:56 ` Patricia Alfonso
2020-03-01 6:39 ` Dmitry Vyukov
2020-03-02 17:52 ` Kees Cook
2020-03-02 22:36 ` Brendan Higgins
2020-03-02 23:02 ` Kees Cook
2020-03-06 23:58 ` Patricia Alfonso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFd5g44gVFyxwo4r=7gpPGdvPQoynfEjHhLfyC3_6uaU2oA0Lg@mail.gmail.com' \
--to=brendanhiggins@google.com \
--cc=alan.maguire@oracle.com \
--cc=aryabinin@virtuozzo.com \
--cc=davidgow@google.com \
--cc=dvyukov@google.com \
--cc=juri.lelli@redhat.com \
--cc=kasan-dev@googlegroups.com \
--cc=kunit-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=trishalfonso@google.com \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).