[PATCH bpf-next v2 2/8] bpf: add BPF_JIT_KASAN for KASAN instrumentation of JITed programs

[Alexis Lothoré]

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-O9c93kk6BwiXgw@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