Re: [PATCH bpf-next 1/1] bpf: btf: add btf=off boot parameter to disable and free vmlinux BTF

From: Alan Maguire

Date: Thu Sep 17 2026 - 03:11:53 EST


On 17/09/2026 05:07, Wang, Jay wrote:
>> Consider using Alan's approach and support CONFIG_DEBUG_INFO_BTF=m
>
> Thanks for the suggestion. We’ll explore how we can make CONFIG_DEBUG_INFO_BTF=m supportable and may post a v2 patch later.
>
> Best,
> Jay
>

See some of the machinery in [1] for hints on how to do this. Ideally
we would want the first user of vmlinux to force the module to load,
/sys/kernel/btf/vmlinux to behave similarly as before etc. The approach
there does this for vmlinux.inline so adapting something like that is
likely the way to go.

The challenging part I suspect will be how to preserve your goal -
avoiding memory allocation - while supporting module BTF. Specifically
for cases where vmlinux BTF has not been used yet and modules load.
Since you'd need to preserve the module BTF for later use on load (due to
the nature of the ELF section it is in), I'm not sure that part would be feasible,
unless you wanted to just support BTF for modules loaded after vmlinux BTF
was.

On-demand vmlinux BTF availability would still be a win.

[1] https://lore.kernel.org/bpf/20260901165757.801449-16-alan.maguire@xxxxxxxxxx/

> On 9/16/26, 6:56 PM, "Alexei Starovoitov" <alexei.starovoitov@xxxxxxxxx <mailto:alexei.starovoitov@xxxxxxxxx>> wrote:
>
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
>
>
>
> On Thu, Sep 17, 2026 at 12:02 AM Jay Wang <wanjay@xxxxxxxxxx <mailto:wanjay@xxxxxxxxxx>> wrote:
>>
>> Add a "btf=off" early boot parameter, similar to the existing "selinux=0"
>> parameter, so users who do not want BTF can turn it off at boot; the
>> section is then freed to save memory.
>
>
> tbh I'm not excited about btf=off. BTF is not debug info anymore.
> sched_ext, bpf-lsm (systemd uses it), hid-bpf, most of bcc/bpftrace
> quietly stop working, and we'll be the ones triaging "libbpf: failed
> to find valid kernel BTF" reports from people who copy-pasted a
> "save 5MB" tuning guide.
> This needs more thought.
>
>
>> .../admin-guide/kernel-parameters.txt | 14 +++
>> arch/arm64/mm/mmu.c | 108 +++++++++++++++++-
>> arch/x86/mm/init_64.c | 30 +++++
>> arch/x86/mm/pat/set_memory.c | 28 ++++-
>> include/linux/btf.h | 9 ++
>> kernel/bpf/btf.c | 51 ++++++++-
>> kernel/bpf/sysfs_btf.c
> | 7 ++
>> kernel/bpf/verifier.c | 2 +-
>
>
> This doesn't apply to bpf-next.
> Consider using Alan's approach and support CONFIG_DEBUG_INFO_BTF=m
>
>
> pw-bot: cr
>
>
>