On Fri May 22, 2026 at 10:14 AM EDT, Alexis Lothoré wrote: > On Tue Apr 14, 2026 at 4:38 PM CEST, Alexei Starovoitov wrote: >> On Tue, Apr 14, 2026 at 6:24 AM Alexis Lothoré >> <[email protected]> wrote: >>> >>> On Tue Apr 14, 2026 at 12:20 AM CEST, Andrey Konovalov wrote: >>> > On Mon, Apr 13, 2026 at 8:29 PM Alexis Lothoré (eBPF Foundation) >>> > <[email protected]> wrote: > > [...] > >>> >> +config BPF_JIT_KASAN >>> >> + bool >>> >> + depends on HAVE_EBPF_JIT_KASAN >>> >> + default y if BPF_JIT && KASAN_GENERIC >>> > >>> > Should this be "depends on KASAN && KASAN_GENERIC"? >>> >>> Meaning, making it an explicit user-selectable option ? >>> >>> If so, the current design choice is voluntary and based on the feedback >>> received on the original RFC, where I have been suggested to >>> automatically enable the KASAN instrumentation in BPF programs if KASAN >>> support is enabled in the kernel ([1]). But if a user-selectable toggle >>> is eventually a better solution, I'm fine with changing it. >> >> Let's not add more config knobs. >> Even this patch looks redundant. >> Inside JIT do instrumentation when KASAN_GENERIC is set. > > (with quite some delay) I think it would be better to keep this new > BPF_JIT_KASAN, because aside from the possibility to use it in > bpf_jit_comp.c, it allows to update tests affected by KASAN > instrumentation in a nicer way. For example, the test_loader subtests > that monitor JITted instructions are confused by KASAN. I can either > skip them or make them smarter when KASAN is enabled for BPF, but in > both cases, it would be nicer to just adapt the behavior based on a > generic CONFIG_BPF_JIT_KASAN, rather than sprinkling some "if > jit_enabled AND CONFIG_KASAN_GENERIC AND ARCH_X86" in selftests. That > still does not make it a config knob, that just creates an internal > Kconfig option that is automatically turned on when KASAN and JIT are > enabled at build time.
Having a togglable config knob gives us the option to set up KASAN for the kernel but not for BPF, and I don't see why we'd want that. Imo we are already paying the cost of KASAN for the rest of the kernel, there is no incentive to not run it for the BPF JIT. Having to eat the complexity cost in the selftests seems reasonable if the alternative means a cleaner interface for the user (preventing them from choosing an unreasonable combination of options).
