On Mon May 25, 2026 at 5:05 AM EDT, Alexis Lothoré wrote: > On Fri May 22, 2026 at 7:13 PM CEST, Emil Tsalapatis wrote: >> 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). > > Again, this does not expose a togglable knob, this is a purely internal > kconfig, automatically enabled if CONFIG_KASAN_GENERIC is set and if the > architecture-specific Kconfig defines HAVE_EBPF_JIT_KASAN (since we want > it for x86 only), and there would be no way to enable KASAN for kernel > only and not for BPF, or the other way around. What I am proposing is > just an internal, architecture-agnostice kconfig to avoid conditioning > some selftests to any architecture.
Makes sense, in this case this seems reasonable. > > Alexis
