On Tue, Apr 14, 2026 at 8:10 AM Andrey Konovalov <[email protected]> wrote: > > On Tue, Apr 14, 2026 at 4:36 PM Alexei Starovoitov > <[email protected]> wrote: > > > > > ACK, I'll try to use those kasan_check_read and kasan_check_write rather > > > than __asan_{load,store}X. > > > > No. The performance penalty will be too high. > > With using __asan_load/storeX(), it will be one function call to get > to check_region_inline(): __asan_load/storeX->check_region_inline. > > With kasan_check_read/write(), right now, it would be two function > calls: __kasan_check_read->kasan_check_range->check_region_inline. > > I doubt an extra function call would make a difference in terms of > performance: the shadow checking itself is also expensive. > > But if the second call is a concern, we can move kasan_check_range() > and lower-level functions into mm/kasan/generic.h and include it into > shadow.c, and then it will be just one function call. > > To improve performance further, the JIT compiler could emit inlined > shadow checking instructions, same as the C compiler does with > KASAN_INLINE=y. > > > hw_tags won't work without corresponding JIT work. > > You probably meant SW_TAGS here. > > HW_TAGS will likely just work without any JIT changes (even the > kasan_check_byte() thing I mentioned should not be required), assuming > JIT'ed BPF code just accesses kernel-returned pointers as is. > > > I see no point sacrificing performance for aesthetics. > > With the change I suggested above, there would be no performance > difference. And the code stays cleaner. > > > __asan_load/storeX is what compilers emit. > > For Generic mode. For SW_TAGS, the function names are different. > Keeping this detail within the KASAN code is cleaner.
I think we're talking past each other. We're not interested in KASAN_SW_TAGS or KASAN_HW_TAGS. We're not going to modify arm64 JIT at all. This is purely KASAN_GENRIC and only on x86-64. JIT will emit exactly what compilers emit for generic which is __asan_load/store. This is as stable ABI as it can get and we don't want to deviate from it. The goal here is to find bugs in the verifier. If something got past it, that shouldn't have, kasan generic on x86-64 is enough.
