On Tue, Apr 14, 2026 at 6:13 AM Alexis Lothoré <[email protected]> wrote: > > Hi Andrey, thanks for the prompt review ! > > On Tue Apr 14, 2026 at 12:19 AM CEST, Andrey Konovalov wrote: > > On Mon, Apr 13, 2026 at 8:29 PM Alexis Lothoré (eBPF Foundation) > > <[email protected]> wrote: > >> > > [...] > > >> +#ifdef CONFIG_KASAN_GENERIC > >> +void __asan_load1(void *p); > >> +void __asan_store1(void *p); > >> +void __asan_load2(void *p); > >> +void __asan_store2(void *p); > >> +void __asan_load4(void *p); > >> +void __asan_store4(void *p); > >> +void __asan_load8(void *p); > >> +void __asan_store8(void *p); > >> +void __asan_load16(void *p); > >> +void __asan_store16(void *p); > >> +#endif /* CONFIG_KASAN_GENERIC */ > > > > This looks ugly, let's not do this unless it's really required. > > > > You can just use kasan_check_read/write() instead - these are public > > wrappers around the same shadow memory checking functions. And they > > also work with the SW_TAGS mode, in case the BPF would want to use > > that mode at some point. (For HW_TAGS, we only have kasan_check_byte() > > that checks a single byte, but it can be extended in the future if > > required to be used by BPF.) > > 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. hw_tags won't work without corresponding JIT work. I see no point sacrificing performance for aesthetics. __asan_load/storeX is what compilers emit. In that sense JIT is a compiler it should emit exactly the same.
