On Tue, Sep 09, 2025 at 10:34:25AM +0200, Peter Zijlstra wrote: > On Tue, Sep 09, 2025 at 10:24:22AM +0200, Maciej Wieczor-Retman wrote: > > On 2025-09-08 at 22:19:05 +0200, Andrey Konovalov wrote: > > >On Mon, Sep 8, 2025 at 3:09 PM Maciej Wieczor-Retman > > ><maciej.wieczor-retman@xxxxxxxxx> wrote: > > >> > > >> >>I recall there were some corner cases where this code path got called in outline > > >> >>mode, didn't have a mismatch but still died due to the die() below. But I'll > > >> >>recheck and either apply what you wrote above or get add a better explanation > > >> >>to the patch message. > > >> > > > >> >Okay, so the int3_selftest_ip() is causing a problem in outline mode. > > >> > > > >> >I tried disabling kasan with kasan_disable_current() but thinking of it now it > > >> >won't work because int3 handler will still be called and die() will happen. > > >> > > >> Sorry, I meant to write that kasan_disable_current() works together with > > >> if(!kasan_report()). Because without checking kasan_report()' return > > >> value, if kasan is disabled through kasan_disable_current() it will have no > > >> effect in both inline mode, and if int3 is called in outline mode - the > > >> kasan_inline_handler will lead to die(). > > > > > >So do I understand correctly, that we have no way to distinguish > > >whether the int3 was inserted by the KASAN instrumentation or natively > > >called (like in int3_selftest_ip())? > > > > > >If so, I think that we need to fix/change the compiler first so that > > >we can distinguish these cases. And only then introduce > > >kasan_inline_handler(). (Without kasan_inline_handler(), the outline > > >instrumentation would then just work, right?) > > > > > >If we can distinguish them, then we should only call > > >kasan_inline_handler() for the KASAN-inserted int3's. This is what we > > >do on arm64 (via brk and KASAN_BRK_IMM). And then int3_selftest_ip() > > >should not be affected. > > > > Looking at it again I suppose LLVM does pass a number along metadata to the > > int3. I didn't notice because no other function checks anything in the x86 int3 > > handler, compared to how it's done on arm64 with brk. > > > > So right, thanks, after fixing it up it shouldn't affect the int3_selftest_ip(). > > Seriously guys, stop using int3 for this. UBSAN uses UD1, why the heck > would KASAN not do the same? Specifically, look at arch/x86/kernel/traps.h:decode_bug(), UBSan uses UD1 /0, I would suggest KASAN to use UD1 /1.
