Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20191119194658.39af50d0@canb.auug.org.au> <e75be639-110a-c615-3ec7-a107318b7746@infradead.org>
 <CANpmjNMpnY54kDdGwOPOD84UDf=Fzqtu62ifTds2vZn4t4YigQ@mail.gmail.com>
 <fb7e25d8-aba4-3dcf-7761-cb7ecb3ebb71@infradead.org> <20191119183407.GA68739@google.com>
 <1574190168.9585.4.camel@lca.pw>
In-Reply-To: <1574190168.9585.4.camel@lca.pw>
From:   Marco Elver <elver@google.com>
Date:   Tue, 19 Nov 2019 20:05:45 +0100
Message-ID: <CANpmjNMfCNqgsXQdDckOg0kuMgvnD8_jka8N0AT2K3hC=CUe0w@mail.gmail.com>
Subject: Re: linux-next: Tree for Nov 19 (kcsan)
To:     Qian Cai <cai@lca.pw>
Cc:     Randy Dunlap <rdunlap@infradead.org>,
        Stephen Rothwell <sfr@canb.auug.org.au>,
        Linux Next Mailing List <linux-next@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        kasan-dev <kasan-dev@googlegroups.com>,
        Dmitry Vyukov <dvyukov@google.com>,
        "Paul E. McKenney" <paulmck@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 19 Nov 2019 at 20:02, Qian Cai <cai@lca.pw> wrote:
>
> On Tue, 2019-11-19 at 19:34 +0100, 'Marco Elver' via kasan-dev wrote:
> > On Tue, 19 Nov 2019, Randy Dunlap wrote:
> >
> > > On 11/19/19 8:12 AM, Marco Elver wrote:
> > > > On Tue, 19 Nov 2019 at 16:11, Randy Dunlap <rdunlap@infradead.org> =
wrote:
> > > > >
> > > > > On 11/19/19 12:46 AM, Stephen Rothwell wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > Changes since 20191118:
> > > > > >
> > > > >
> > > > > on x86_64:
> > > > >
> > > > > It seems that this function can already be known by the compiler =
as a
> > > > > builtin:
> > > > >
> > > > > ../kernel/kcsan/core.c:619:6: warning: conflicting types for buil=
t-in function =E2=80=98__tsan_func_exit=E2=80=99 [-Wbuiltin-declaration-mis=
match]
> > > > >  void __tsan_func_exit(void)
> > > > >       ^~~~~~~~~~~~~~~~
> > > > >
> > > > >
> > > > > $ gcc --version
> > > > > gcc (SUSE Linux) 7.4.1 20190905 [gcc-7-branch revision 275407]
> > > >
> > > > Interesting. Could you share the .config? So far I haven't been abl=
e
> > > > to reproduce.
> > >
> > > Sure, it's attached.
> >
> > Thanks, the config did the trick, even for gcc 9.0.0.
> >
> > The problem is CONFIG_UBSAN=3Dy. We haven't explicitly disallowed it li=
ke
> > with KASAN. In principle there should be nothing wrong with KCSAN+UBSAN=
.
> >
> > There are 3 options:
> > 1. Just disable UBSAN for KCSAN, and also disable KCSAN for UBSAN.
> > 2. Restrict the config to not allow combining KCSAN and UBSAN.
> > 3. Leave things as-is.
> >
> > Option 1 probably makes most sense, and I'll send a patch for that
> > unless there are major objections.
>
> Both option #1 and #2 sounds quite unfortunate, as UBSAN is quite valuabl=
e for
> debugging. Hence, it is desire to make both work at the same time.

Apologies, I think I was a bit unclear with #1. For #1, this just
means that UBSAN is being disabled for the KCSAN runtime and
vice-versa. All other parts of the kernel are still instrumented with
both.

See here: https://lore.kernel.org/linux-next/20191119185742.GB68739@google.=
com/

Thanks,
-- Marco