[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CABVgOS=k2eCMwt-Tz46=mCXg1Kxjb54sD1kW-R=mchFQiCgYTQ@mail.gmail.com>
Date: Fri, 24 Apr 2020 14:36:48 +0800
From: David Gow <davidgow@...gle.com>
To: Alan Maguire <alan.maguire@...cle.com>
Cc: Patricia Alfonso <trishalfonso@...gle.com>,
Brendan Higgins <brendanhiggins@...gle.com>,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Juri Lelli <juri.lelli@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
kasan-dev <kasan-dev@...glegroups.com>,
KUnit Development <kunit-dev@...glegroups.com>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@...r.kernel.org>
Subject: Re: [PATCH v6 0/5] KUnit-KASAN Integration
On Sat, Apr 18, 2020 at 11:28 PM Alan Maguire <alan.maguire@...cle.com> wrote:
>
>
> On Fri, 17 Apr 2020, David Gow wrote:
>
> > This patchset contains everything needed to integrate KASAN and KUnit.
> >
> > KUnit will be able to:
> > (1) Fail tests when an unexpected KASAN error occurs
> > (2) Pass tests when an expected KASAN error occurs
> >
> > Convert KASAN tests to KUnit with the exception of copy_user_test
> > because KUnit is unable to test those.
> >
>
> I tried building and running and things look good but I am
> still seeing the three failures I reported before, even with
> CONFIG_AMD_MEM_ENCRYPT not set. My config is attached if you
> want to try and reproduce at your end. Oddly this config was
> working before IIRC (once CONFIG_AMD_MEM_ENCRYPT was not set).
>
> Here's the failures:
>
> # kasan_memchr: EXPECTATION FAILED at lib/test_kasan.c:545
> Expected fail_data.report_expected == fail_data.report_found, but
> fail_data.report_expected == 1
> fail_data.report_found == 0
> not ok 31 - kasan_memchr
> # kasan_memcmp: EXPECTATION FAILED at lib/test_kasan.c:566
> Expected fail_data.report_expected == fail_data.report_found, but
> fail_data.report_expected == 1
> fail_data.report_found == 0
> not ok 32 - kasan_memcmp
I was able to reproduce these (along with a kasan_strings) failure,
and the cause seems to be some combination of __builtin functions
being inlined by the compiler and potentially dead code elimination,
as fixed by Daniel Axtens here:
https://lkml.org/lkml/2020/4/23/708
I've sent out v7 of the patchset[1], which I've rebased on top of
Daniel's patches, and can no longer reproduce those test failures with
your .config.
Cheers,
-- David
[1]: https://lkml.org/lkml/2020/4/24/80
Powered by blists - more mailing lists