From: "Alexis Lothoré" <alexis.lothore@bootlin.com>
To: sashiko@lists.linux.dev,
"Alexis Lothoré (eBPF Foundation)" <alexis.lothore@bootlin.com>
Cc: <bpf@vger.kernel.org>
Subject: Re: [PATCH RFC bpf-next 3/8] bpf: add BPF_JIT_KASAN for KASAN instrumentation of JITed programs
Date: Wed, 29 Apr 2026 23:04:24 +0200 [thread overview]
Message-ID: <DI5XZAYSH081.1FI819ZYQZW8L@bootlin.com> (raw)
In-Reply-To: <20260425051840.1E7C1C2BCB2@smtp.kernel.org>
On Sat Apr 25, 2026 at 7:18 AM CEST, sashiko-bot wrote:
> Sashiko AI review found 2 potential issue(s):
> - [Medium] BPF_JIT_KASAN is defined as a hidden config, preventing users from disabling it.
> - [Medium] Mismatch between commit message claims and Kconfig implementation regarding KASAN modes.
> --
[...]
>> @@ -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
>> +
>> endmenu # "BPF subsystem"
>
> Since this config is defined as a bool without a prompt string, it acts as a
> hidden symbol that is forcefully enabled whenever its dependencies are met.
>
> Because KASAN instrumentation emits shadow memory checks, it can significantly
> inflate the size of generated JIT code.
>
> Could this code expansion cause large BPF programs to exceed the strict BPF
> JIT memory limits (bpf_jit_limit) and break BPF functionality?
It likely can, indeed, but...
> If so, would it make sense to provide a prompt text so users and automated
> testing systems have a mechanism to manually disable CONFIG_BPF_JIT_KASAN
> to work around JIT limits or isolate bugs without having to entirely disable
> KASAN_GENERIC?
... the discussions around this RFC rather tend make the series go in
the opposite direction ([1]) and keep it systematically enabled if KASAN
is enabled (I'll even drop this patch in the next revision and just make
the KASAN code in JIT directly depend on KASAN_GENERIC).
[1] https://lore.kernel.org/bpf/CAADnVQLj=UosnsC-4V2+mN92Fe0-kW++U+m-O9c93kk6BwiXgw@mail.gmail.com/
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
parent reply other threads:[~2026-04-29 21:04 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20260425051840.1E7C1C2BCB2@smtp.kernel.org>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DI5XZAYSH081.1FI819ZYQZW8L@bootlin.com \
--to=alexis.lothore@bootlin.com \
--cc=bpf@vger.kernel.org \
--cc=sashiko@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox