Re: [PATCH bpf-next v4 00/12] bpf: make the vmlinux BTF an on-demand loadable module (CONFIG_DEBUG_INFO_BTF=m) to save ~5.4 MB memory

[Ihor Solodrai]

On 2026-10-01 3:52 p.m., Jay Wang wrote:
> Based on and tested against bpf-next commit b5a4aa31abd6 ("bpf, cgroup:
> Fix cgroup struct_ops query for a second attach type").
>
> This series makes CONFIG_DEBUG_INFO_BTF a tristate, so that it can be
> set to =m.  With =m the vmlinux BTF is carried by a module, btf_vmlinux,
> that the kernel loads the first time user space asks for something that
> needs the BTF.  On a system where nothing does, that saves ~5.4 MB of
> RAM with a distribution config; on a system that uses BTF, it behaves as
> with =y.  =y itself is untouched.
>
> Problem
> -------
>
> The vmlinux BTF that CONFIG_DEBUG_INFO_BTF=y builds into the kernel
> image takes ~5.4 MB of memory, resident from boot whether anything uses
> it or not.  On small instances that is not negligible.
>
> A distribution cannot simply turn it off for the users who do not need
> it: it ships one kernel build for all its users, and BTF is not debug
> info anymore.  CO-RE, fentry/fexit, kfuncs, struct_ops, sched_ext and
> bpf-lsm all depend on it, so =n takes those away from everyone who does
> use them.
>
> Hence this series adds CONFIG_DEBUG_INFO_BTF=m: the BTF becomes an
> on-demand module.  Users who never use BTF get the memory back; for
> users who do, the first request that needs it loads it, and everything
> works as with =y.
>
> [...]
>
>   Documentation/bpf/btf.rst                  |   68 ++
>   Makefile                                   |    8 +-
>   include/asm-generic/vmlinux.lds.h          |   32 +-
>   include/linux/bpf.h                        |   15 +
>   include/linux/btf.h                        |   11 +
>   include/linux/btf_ids.h                    |    2 +-
>   include/linux/compiler_types.h             |    2 +-
>   include/linux/module.h                     |    2 +-
>   include/trace/trace_events.h               |    2 +-
>   init/Kconfig                               |    2 +-
>   kernel/bpf/Makefile                        |    6 +-
>   kernel/bpf/bpf_struct_ops.c                |    3 +-
>   kernel/bpf/btf.c                           | 1085 ++++++++++++++++++--
>   kernel/bpf/btf_vmlinux.c                   |   23 +
>   kernel/bpf/inode.c                         |   44 +-
>   kernel/bpf/preload/Kconfig                 |    4 +
>   kernel/bpf/syscall.c                       |   51 +-
>   kernel/bpf/sysfs_btf.c                     |   97 +-
>   kernel/bpf/verifier.c                      |  172 +++-
>   kernel/module/Kconfig                      |    2 +-
>   kernel/module/main.c                       |    4 +-
>   kernel/trace/bpf_trace.c                   |    3 +-
>   kernel/trace/trace_events.c                |   10 +
>   kernel/trace/trace_output.c                |    7 +
>   kernel/trace/trace_probe.c                 |   16 +
>   kernel/trace/trace_syscalls.c              |    6 +-
>   lib/Kconfig.debug                          |   30 +-
>   net/netfilter/Makefile                     |    6 +-
>   net/xfrm/Makefile                          |    4 +-
>   samples/bpf/Makefile                       |    6 +-
>   samples/hid/Makefile                       |    6 +-
>   scripts/Makefile.modfinal                  |   28 +-
>   scripts/Makefile.vmlinux                   |    5 +
>   scripts/gen-btf.sh                         |   53 +-
>   scripts/link-vmlinux.sh                    |   25 +-
>   scripts/package/PKGBUILD                   |    7 +
>   scripts/package/kernel.spec                |    4 +
>   scripts/package/mkspec                     |    7 +
>   tools/bpf/bpftool/Makefile                 |    6 +-
>   tools/bpf/resolve_btfids/main.c            |  217 +++-
>   tools/perf/bpf_skel.mak                    |    8 +-
>   tools/sched_ext/Makefile                   |    6 +-
>   tools/testing/selftests/bpf/Makefile       |    6 +-
>   tools/testing/selftests/hid/Makefile       |    6 +-
>   tools/testing/selftests/sched_ext/Makefile |    6 +-
>   45 files changed, 1936 insertions(+), 177 deletions(-)

This series caught my attention because of the sheer amount of the code
and the iteration speed. I've tried to read the cover (it was
tiresome, please ask your "agent" to be concise), and fed the series
to my bot.

A question I had: is it really worth 2k of complicated kernel code to
*maybe sometimes* save <10Mb of memory?

And then the bot found this:

    What systemd does at every boot

    PID1 loads and attaches a BTF-dependent LSM program at every boot

      src/core/manager.c:1026-1059, in manager_new():

      if (FLAGS_SET(test_run_flags, MANAGER_TEST_RUN_MINIMAL)) {
              ...
      } else {
              ...
              (void) bpf_restrict_fs_setup(m);
      }

https://github.com/systemd/systemd/blob/main/src/core/manager.c#L1026-L1059
https://github.com/systemd/systemd/blob/main/src/core/bpf-restrict-fs.c#L27-L85

Do those tiny VMs that you target run systemd with BPF LSM?
I assume you target concrete VMs, not "small instances" in a vacuum.

You can check this by booting them with =m and then:
  $ lsmod | grep btf_vmlinux
  $ systemctl --version  # look for +BPF_FRAMEWORK
  $ cat /sys/kernel/security/lsm

If the answer is "yes" for the majority of them, the whole project is
moot, because the module will be loaded immediately on boot.

My bot found more stuff implementation-wise...

I suggest to slow down, stop burning tokens for a bit, and first try
to figure out the important details:
  - who will actually benefit from these memory savings and do they care?
  - is it worth it in terms of implementation complexity?

Even for LLM it's easier to deal with a 100 lines of code than with 2k.

pw-bot: cr

>   create mode 100644 kernel/bpf/btf_vmlinux.c
>
>
> base-commit: b5a4aa31abd6fe90009b63e35dc18c67d041ec0c