Re: PANIC: double fault in fixup_bad_iret

[Marco Elver]

On Sun, 31 May 2020 at 11:32, Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote:
>
> On Fri, May 29, 2020 at 7:11 PM Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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.GN706495@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

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