Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <5f60c4e0.Ru0MTgSE9A7mqhpG%lkp@intel.com> <20200915135519.GJ14436@zn.tnic>
 <20200915141816.GC28738@shao2-debian> <20200915160554.GN14436@zn.tnic>
 <20200915170248.gcv54pvyckteyhk3@treble> <CAKwvOdnc8au10g8q8miab89j3tT8UhwnZOMAJdRgkXVrnkhwqQ@mail.gmail.com>
 <CAKwvOdmNzapwEo26m0soAR2OLFxOoERPKbKgvQ0bfoqjNkEVCg@mail.gmail.com> <20200915212804.vvm7ovffqynkvi5a@treble>
In-Reply-To: <20200915212804.vvm7ovffqynkvi5a@treble>
From:   Marco Elver <elver@google.com>
Date:   Wed, 16 Sep 2020 01:35:52 +0200
Message-ID: <CANpmjNMWtZCUv-yB5eRBXaB=FLZESmtruq56Q3dS7hu2zDr9kQ@mail.gmail.com>
Subject: Re: [tip:x86/seves] BUILD SUCCESS WITH WARNING e6eb15c9ba3165698488ae5c34920eea20eaa38e
To:     Josh Poimboeuf <jpoimboe@redhat.com>
Cc:     Nick Desaulniers <ndesaulniers@google.com>,
        Borislav Petkov <bp@alien8.de>,
        Rong Chen <rong.a.chen@intel.com>,
        kernel test robot <lkp@intel.com>,
        "Li, Philip" <philip.li@intel.com>, x86-ml <x86@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        clang-built-linux <clang-built-linux@googlegroups.com>,
        Arnd Bergmann <arnd@arndb.de>,
        Kees Cook <keescook@chromium.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 15 Sep 2020 at 23:28, Josh Poimboeuf <jpoimboe@redhat.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