Re: [PATCH bpf-next 6/6] kbuild, bpf: allow building the vmlinux BTF as a module

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] kbuild: global module relinks when CONFIG_DEBUG_INFO_BTF=m
- [Low] kbuild: non-POSIX head -c in gen-btf.sh breaks strict environments
--

commit 7587d72dd889263f91882b475224bac4cf470c15
Author: Jay Wang <wanjay@amazon.com>

kbuild, bpf: allow building the vmlinux BTF as a module

This commit makes CONFIG_DEBUG_INFO_BTF a tristate, allowing the vmlinux BTF 
to be built as a module (btf_vmlinux) rather than part of the kernel image. 
It defers loading the BTF until it is first needed, saving memory on systems 
where it goes unused.

> diff --git a/scripts/Makefile.modfinal b/scripts/Makefile.modfinal
> index 01a37ec872b90..ad182f84b5fcf 100644
> --- a/scripts/Makefile.modfinal
> +++ b/scripts/Makefile.modfinal

[ ... ]

> -# Re-generate module BTFs if either module's .ko or vmlinux changed
> -%.ko: %.o %.mod.o .module-common.o $(objtree)/scripts/module.lds $(and $(CONFIG_DEBUG_INFO_BTF_MODULES),$(KBUILD_BUILTIN),$(objtree)/vmlinux) FORCE
> -	+$(call if_changed,ld_ko_o)
> +# Modules that get a .BTF section: all of them with CONFIG_DEBUG_INFO_BTF_MODULES,
> +# otherwise only the vmlinux BTF carrier module with CONFIG_DEBUG_INFO_BTF=m.
>  ifdef CONFIG_DEBUG_INFO_BTF_MODULES
> -	+$(if $(newer-prereqs),$(call cmd,btf_ko))
> +btf-modules := $(modules:%.o=%.ko)
> +else ifeq ($(CONFIG_DEBUG_INFO_BTF),m)
> +btf-modules := $(filter %/btf_vmlinux.ko,$(modules:%.o=%.ko))
>  endif
> +
> +# Re-generate module BTFs if either module's .ko or vmlinux changed
> +%.ko: %.o %.mod.o .module-common.o $(objtree)/scripts/module.lds $(and $(btf-modules),$(KBUILD_BUILTIN),$(objtree)/vmlinux) FORCE

[Severity: High]
Will this implicit rule globally add vmlinux as a prerequisite to every module
if btf-modules is non-empty?

When CONFIG_DEBUG_INFO_BTF=m and CONFIG_DEBUG_INFO_BTF_MODULES is disabled,
btf-modules evaluates to kernel/bpf/btf_vmlinux.ko. Since btf-modules is
non-empty, the $(and $(btf-modules),$(KBUILD_BUILTIN),$(objtree)/vmlinux)
expression will evaluate to $(objtree)/vmlinux for the generic %.ko target.

Does this inject vmlinux as a prerequisite for every module in the tree (not
just btf_vmlinux.ko), triggering broad unnecessary relinks of all kernel
modules whenever a built-in file is modified during incremental builds?

> +	+$(call if_changed,ld_ko_o)
> +	+$(if $(and $(filter $@,$(btf-modules)),$(newer-prereqs)),$(call cmd,btf_ko))
>  	+$(call cmd,check_tracepoint)

[ ... ]

> diff --git a/scripts/gen-btf.sh b/scripts/gen-btf.sh
> index 8ca96eb10a69e..7fa3189a3ded8 100755
> --- a/scripts/gen-btf.sh
> +++ b/scripts/gen-btf.sh

[ ... ]

> @@ -133,6 +190,34 @@ if [ -n "${BTF_BASE}" ]; then
>  	BTFGEN_MODE="module"
>  fi
>  
> +if [ -n "${PLACEHOLDER}" ]; then
> +	btf_data=${ELF_FILE}.btf.o
> +	echo "" | ${CC} ${CLANG_FLAGS} ${KBUILD_CPPFLAGS} ${KBUILD_CFLAGS} -fno-lto -c -x c -o ${btf_data} -
> +	head -c 36 /dev/zero > ${ELF_FILE}.BTF.meta

[Severity: Low]
Is it safe to use the non-POSIX -c flag for head here?

The -c option is a GNU/Busybox extension and is not defined in the
POSIX.1-2017 standard. On strict environments where head only accepts
the -n flag, will this cause the kernel build to fail?

> +	${OBJCOPY} --add-section .BTF.meta=${ELF_FILE}.BTF.meta \
> +		--set-section-flags .BTF.meta=alloc,readonly ${btf_data}
> +	${OBJCOPY} --only-section=.BTF.meta --strip-all ${btf_data}
> +	exit 0
> +fi
> +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260923053948.30617-1-wanjay@amazon.com?part=6