From: David Gow <davidgow@google.com>
To: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Andrey Konovalov <andreyknvl@google.com>,
Alexander Potapenko <glider@google.com>,
Andrey Ryabinin <ryabinin.a.a@gmail.com>,
Dmitry Vyukov <dvyukov@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
kasan-dev@googlegroups.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
Daniel Latypov <dlatypov@google.com>,
Brendan Higgins <brendanhiggins@google.com>,
linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com
Subject: Re: [PATCH] kasan: Enable KUnit integration whenever CONFIG_KUNIT is enabled
Date: Thu, 20 Oct 2022 14:38:02 +0800 [thread overview]
Message-ID: <CABVgOSnC3Y4Dq4evkghiKpDYSe_kSeCQPo6193H0_WxQyx0EFg@mail.gmail.com> (raw)
In-Reply-To: <CA+fCnZcea7UrA11HyRB80WgrUXMtEkK0AjdxEN=H-pMuWBhQyQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2761 bytes --]
On Thu, Oct 20, 2022 at 3:48 AM Andrey Konovalov <andreyknvl@gmail.com> wrote:
>
> On Wed, Oct 19, 2022 at 5:06 PM David Gow <davidgow@google.com> wrote:
> >
> > > 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/kasan/report.c#n130
>
> Ah, right. Thanks for the explanation!
>
> > > 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.
>
> I wonder what's the best solution to support this, assuming KASAN
> tests are switched to using tracepoints... I guess we could still keep
> the per-task KUnit flag, and only use it for non-KASAN tests. However,
> they will still suffer from the same issue tracepoints solve for KASAN
> tests: if a bug is triggered in a context other than the current task,
> the test will succeed.
Yeah: I'm not sure what the perfect solution here is. Ideally, we'd
have some good way to get the current test, which would work even in
workqueues, rcu, etc. This affects more than just KASAN: there are
quite a few different places where getting "the current test" is
important. One option is just to use a global: we don't support
running multiple simultaneous KUnit tests at all, at the moment. But,
equally, it increases the possibility of false-positives if something
non-test related needs to access the test structure. This is probably
not too much of a problem for KASAN, but the function redirection
features we're working on benefit quite a bit from those redirections
not being enabled outside of the test.
Thus far, we've just sort-of accepted that these don't work with tests
which push work to other tasks, but it is sub-optimal. And even if
KASAN moves to tracepoints, this problem doesn't totally go away, as
you still need some way to know you're in the KASAN test to disable
the "fail-test-on-KASAN-report" behaviour. I guess that could be some
global flag triggered from the suite_init / suite_exit for the KASAN
test, though.
Cheers,
-- David
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4003 bytes --]
prev parent reply other threads:[~2022-10-20 6:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-19 8:57 David Gow
2022-10-19 14:17 ` Andrey Konovalov
2022-10-19 15:06 ` David Gow
2022-10-19 19:48 ` Andrey Konovalov
2022-10-20 6:38 ` David Gow [this message]
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=CABVgOSnC3Y4Dq4evkghiKpDYSe_kSeCQPo6193H0_WxQyx0EFg@mail.gmail.com \
--to=davidgow@google.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=andreyknvl@google.com \
--cc=brendanhiggins@google.com \
--cc=dlatypov@google.com \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=kunit-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ryabinin.a.a@gmail.com \
--cc=vincenzo.frascino@arm.com \
/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