> 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? --- 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
