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. > In that sense JIT is a compiler it should emit exactly the same.
