linux-kernel - Re: [PATCH v2] kcsan: Add test suite

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 6 May 2020 12:26:25 +0200
From:   Marco Elver <elver@...gle.com>
To:     David Gow <davidgow@...gle.com>
Cc:     "Paul E. McKenney" <paulmck@...nel.org>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Alexander Potapenko <glider@...gle.com>,
        Andrey Konovalov <andreyknvl@...gle.com>,
        kasan-dev <kasan-dev@...glegroups.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        KUnit Development <kunit-dev@...glegroups.com>
Subject: Re: [PATCH v2] kcsan: Add test suite

On Wed, 6 May 2020 at 06:45, David Gow <davidgow@...gle.com> wrote:
>
> On Wed, May 6, 2020 at 2:30 AM Marco Elver <elver@...gle.com> wrote:
> >
> > This adds KCSAN test focusing on behaviour of the integrated runtime.
> > Tests various race scenarios, and verifies the reports generated to
> > console. Makes use of KUnit for test organization, and the Torture
> > framework for test thread control.
> >
> > Signed-off-by: Marco Elver <elver@...gle.com>
>
> Thanks, this works much better on my setup: having an explicit error
> for there not being enough CPUs is a lot better than hanging. It'd
> still be nice to have these be "skipped" rather than "failed" at some
> stage, but that's a nice-to-have for the future once we've implemented
> such a thing in KUnit.

Will keep an eye on KUnit adding support for this, and in future we
can change it. Although I'd argue that these tests failing is a signal
that a particular KCSAN based CI setup isn't terribly useful at
finding data races, which can still be a valuable signal to have.

> I'm still a little hesitant about non-deterministic tests in general —
> even if they're only run when CONFIG_KCSAN is enabled, it's possible
> that a future CI system could run under KCSAN and report false
> breakages on unrelated patches. Given no such setup exists yet,
> though, I think it's probably a problem for the future rather than a
> blocker at the moment.

True. But as noted above, it might also highlight an issue with the CI
system's ability to detect data races if KCSAN is enabled, which is
the whole point of having a KCSAN test setup. But yes, let's cross
that bridge when such a system actually exists.

> Regardless, I hit no unexpected issues in my testing, so,
>
> Tested-by: David Gow <davidgow@...gle.com>

Thank you for testing!

-- Marco