[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANpmjNMWtZCUv-yB5eRBXaB=FLZESmtruq56Q3dS7hu2zDr9kQ@mail.gmail.com>
Date: Wed, 16 Sep 2020 01:35:52 +0200
From: Marco Elver <elver@...gle.com>
To: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: Nick Desaulniers <ndesaulniers@...gle.com>,
Borislav Petkov <bp@...en8.de>,
Rong Chen <rong.a.chen@...el.com>,
kernel test robot <lkp@...el.com>,
"Li, Philip" <philip.li@...el.com>, x86-ml <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
clang-built-linux <clang-built-linux@...glegroups.com>,
Arnd Bergmann <arnd@...db.de>,
Kees Cook <keescook@...omium.org>
Subject: Re: [tip:x86/seves] BUILD SUCCESS WITH WARNING e6eb15c9ba3165698488ae5c34920eea20eaa38e
On Tue, 15 Sep 2020 at 23:28, Josh Poimboeuf <jpoimboe@...hat.com> wrote:
> On Tue, Sep 15, 2020 at 02:13:01PM -0700, Nick Desaulniers wrote:
> > Triple checking what I wrote above; it looks like the randconfig had
> > BOTH CONFIG_KASAN=y and CONFIG_UBSAN=y enabled. Aren't the sanitizers
> > supposed to be mutually exclusive? If so, we should ensure that via
> > kconfig these can't be selected together via randconfig.
>
> No idea...
They are not mutually exclusive. The big ones like KASAN/KCSAN/KMSAN
are mutually exclusive (compiler complains if you mix the flags), but
UBSAN can be enabled with other sanitizers (and fsanitize-coverage,
although not strictly a "sanitizer" it's still instrumentation based).
In general, we shouldn't artificially disallow mixing them if it's
supported by the compiler and our runtime can handle it.
I'll have a look at the rest tomorrow (UBSAN_TRAP stuff, which
coincidentally also came up in some other patch).
Thanks,
-- Marco
Powered by blists - more mailing lists