On Tue, Apr 14, 2026 at 11:41 AM Alexis Lothoré <[email protected]> wrote: > > On Tue Apr 14, 2026 at 4:36 PM CEST, Alexei Starovoitov wrote: > > 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. > > Since we are mentioning it, I did not consider yet any performance > comparision/benchmarking (and I am not really familiar with usual bpf > performance validation practices for new bpf features). Is there any > existing test I should take a look at for this ? Maybe some specific > benches in tools/testing/selftests/bpf/bench ?
So far everything in bpf/bench/ measures bpf infra like maps, kprobes, tracepoints, etc. We don't have benchmarks for bpf programs. So we don't know how well JITs are generating code and how much inlining done by the verifier, JITs actually helps. Puranjay is working on creating a SPECint like set of benchmarks. For this kasan work we should make the best decisions from performance point of view, like not wasting unnecessary call and not saving unnecessary registers. btw in the other patch I think you can skip saving of r10 and r11. But we cannot quantify yet that avoiding extra call gives us N%. You can micro-benchmark, of course, but gotta be careful interpreting the results. It might be too easy to get into thinking that JIT must inline __asan_load() for the sake of performance.
