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. -- Alexis Lothoré, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
