On Sun, 31 May 2020 at 11:32, Dmitry Vyukov <dvyu...@google.com> wrote: > > On Fri, May 29, 2020 at 7:11 PM Peter Zijlstra <pet...@infradead.org> wrote: > > > Like with KCSAN, we should blanket kill KASAN/UBSAN and friends (at the > > > very least in arch/x86/) until they get that function attribute stuff > > > sorted. > > > > Something like so. > > > > --- > > diff --git a/arch/x86/Makefile b/arch/x86/Makefile > > index 00e378de8bc0..a90d32b87d7e 100644 > > --- a/arch/x86/Makefile > > +++ b/arch/x86/Makefile > > @@ -1,6 +1,14 @@ > > # SPDX-License-Identifier: GPL-2.0 > > # Unified Makefile for i386 and x86_64 > > > > +# > > +# Until such a time that __no_kasan and __no_ubsan work as expected (and > > are > > +# made part of noinstr), don't sanitize anything. > > +# > > +KASAN_SANITIZE := n > > +UBSAN_SANITIZE := n > > +KCOV_INSTRUMENT := n > > + > > # select defconfig based on actual architecture > > ifeq ($(ARCH),x86) > > ifeq ($(shell uname -m),x86_64) > > +kasan-dev > +Marco, please send a fix for this
I think Peter wanted to send a patch to add __no_kcsan to noinstr: https://lkml.kernel.org/r/20200529170755.gn706...@hirez.programming.kicks-ass.net In the same patch we can add __no_sanitize_address to noinstr. But: - We're missing a definition for __no_sanitize_undefined and __no_sanitize_coverage. - Could optionally add __no_{kasan,ubsan,kcov}, to be consistent with __no_kcsan, although I'd just keep __no_sanitize for the unambiguous names (__no_kcsan is special because __no_sanitize_thread and TSAN instrumentation is just an implementation detail of KCSAN, which != KTSAN). - We still need the above blanket no-instrument for x86 because of GCC. We could guard it with "ifdef CONFIG_CC_IS_GCC". Not sure what the best strategy is to minimize patch conflicts. For now I could send just the patches to add missing definitions. If you'd like me to send all patches (including modifying 'noinstr'), let me know. Thanks, -- Marco
