Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220416081355.2155050-1-jcmvbkbc@gmail.com> <CANpmjNNW0kLf2Ou6i_dNeRLO=Qrru4bOEfJ=be=Dfig4wnQ67g@mail.gmail.com>
 <CAMo8BfJM0JHqh8Nz3LuK7Ccu7WB1Cup0mX+RYvO1yft_K4hyLQ@mail.gmail.com>
 <Yl/Mh4gjG1hYW2nA@elver.google.com> <CAMo8BfLANCoLa4zXO4aYmX0Wk7fV7_wei04MveLHu=d2RDZ77w@mail.gmail.com>
In-Reply-To: <CAMo8BfLANCoLa4zXO4aYmX0Wk7fV7_wei04MveLHu=d2RDZ77w@mail.gmail.com>
From:   Marco Elver <elver@google.com>
Date:   Thu, 21 Apr 2022 00:58:50 +0200
Message-ID: <CANpmjNO1WDCgv_cPVMKe3G31Kwqtbg__QqpsotkkVFY-5U2y6A@mail.gmail.com>
Subject: Re: [PATCH] xtensa: enable KCSAN
To:     Max Filippov <jcmvbkbc@gmail.com>
Cc:     "open list:TENSILICA XTENSA PORT (xtensa)" 
        <linux-xtensa@linux-xtensa.org>, Chris Zankel <chris@zankel.net>,
        LKML <linux-kernel@vger.kernel.org>,
        Dmitry Vyukov <dvyukov@google.com>, kasan-dev@googlegroups.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, 20 Apr 2022 at 20:11, Max Filippov <jcmvbkbc@gmail.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.)