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  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

Powered by blists - more mailing lists