On Thu Jun 4, 2026 at 11:13 PM CEST, bot+bpf-ci wrote: >> diff --git a/kernel/bpf/Kconfig b/kernel/bpf/Kconfig >> index eb3de35734f0..a8e004f88b92 100644 >> --- a/kernel/bpf/Kconfig >> +++ b/kernel/bpf/Kconfig > > [ ... ] > >> @@ -101,4 +105,9 @@ config BPF_LSM >> >> If you are unsure how to answer this question, answer N. >> >> +config BPF_JIT_KASAN >> + bool >> + depends on HAVE_EBPF_JIT_KASAN >> + default y if BPF_JIT && KASAN_GENERIC && KASAN_VMALLOC && VMAP_STACK >> + >> endmenu # "BPF subsystem" > > This isn't a bug, but a design concern raised on an earlier posting of > this work doesn't look fully resolved. > > In the v1 (RFC) discussion, the suggestion was to not add a config knob > at all and instead do the instrumentation inside the JIT whenever > KASAN_GENERIC is set: > > "Let's not add more config knobs. Even this patch looks redundant. > Inside JIT do instrumentation when KASAN_GENERIC is set." > > > https://lore.kernel.org/bpf/CAADnVQLj=uosnsc-4v2+mn92fe0-kw++u+m-o9c93kk6bwi...@mail.gmail.com/ > > The reasoning given for keeping the internal Kconfig was that it lets > selftests adapt their behavior without sprinkling arch and KASAN > conditionals, and another reviewer agreed that approach was reasonable. > > That "this patch looks redundant" objection was never explicitly > retracted or re-acked, yet the BPF_JIT_KASAN config is retained here. > > Has this design point been settled?
I still advocate to keep this BPF_JIT_KASAN, which is used later in patch 7/8 to check whether kasan tests should be executed or not. Alexis > > --- > AI reviewed your patch. Please fix the bug or email reply why it's not a bug. > See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md > > CI run summary: https://github.com/kernel-patches/bpf/actions/runs/26978380520 -- Alexis Lothoré, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
