[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANpmjNO1WDCgv_cPVMKe3G31Kwqtbg__QqpsotkkVFY-5U2y6A@mail.gmail.com>
Date: Thu, 21 Apr 2022 00:58:50 +0200
From: Marco Elver <elver@...gle.com>
To: Max Filippov <jcmvbkbc@...il.com>
Cc: "open list:TENSILICA XTENSA PORT (xtensa)"
<linux-xtensa@...ux-xtensa.org>, Chris Zankel <chris@...kel.net>,
LKML <linux-kernel@...r.kernel.org>,
Dmitry Vyukov <dvyukov@...gle.com>, kasan-dev@...glegroups.com
Subject: Re: [PATCH] xtensa: enable KCSAN
On Wed, 20 Apr 2022 at 20:11, Max Filippov <jcmvbkbc@...il.com> wrote:
> > Each test case is run with varying number of threads - am I correctly
> > inferring that out of all test cases, usually only one such run failed,
> > and runs with different number of threads (of the same test case)
> > succeeded?
>
> For most of the failures -- yes.
> For the test_missing_barrier and test_atomic_builtins_missing_barrier
> on the hardware it was the opposite: only one subtest succeeded while
> all others failed. Does it mean that the xtensa memory model is
> insufficiently weak?
No - KCSAN's weak memory modeling and detection of missing barriers
doesn't care what the HW does, it only approximates the LKMM. If the
test_barrier_nothreads case passed, there's nothing wrong with barrier
instrumentation. Regarding the test case failures, if at least 1
passed I'm guessing it's just flaky (not enough concurrency, or
unexpected barriers due to too many interrupts which can happen if we
enter the scheduler).
Unfortunately I don't know xtensa and if this is normal, but modulo
flakiness, I think it's fine. (I've made a note to try and deflake the
test if I can find time to try the xtensa version.)
Powered by blists - more mailing lists