Re: [PATCH bpf-next] btf: Remove the dependency on BPF_SYSCALL

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Enabling CONFIG_DEBUG_INFO_BTF without CONFIG_BPF causes a build failure because resolve_btfids is not built.
- [High] Removing `depends on BPF_SYSCALL` from `CONFIG_DEBUG_INFO_BTF` causes a build failure (undefined reference to bpf_log) when `CONFIG_BPF_SYSCALL=n`.
- [Medium] The BTF sysfs interface (/sys/kernel/btf/vmlinux) is silently omitted if CONFIG_BPF is disabled, breaking runtime introspection tools.
- [Low] Unintended dead code compilation in BPF network/netfilter helpers when `CONFIG_BPF_SYSCALL=n`.
--

--- Patch [1]: [PATCH bpf-next] btf: Remove the dependency on BPF_SYSCALL ---
commit 03ceb2b61ee22ba44c522bd10633e606cb023951
Author: Thomas Weißschuh <[email protected]>

btf: Remove the dependency on BPF_SYSCALL
    
BTF has become useful without the BPF syscall being present.
It is used by debuggers and introspection tools like pahole.
The dependency prevents the usage of BTF without pulling in the
rest of the BPF subsystem.
    
Remove the dependency.

> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 1244dcac2294a..f9dc5b60d8345 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -399,7 +399,6 @@ config DEBUG_INFO_BTF
>  	bool "Generate BTF type information"
>  	depends on !DEBUG_INFO_SPLIT && !DEBUG_INFO_REDUCED
>  	depends on !GCC_PLUGIN_RANDSTRUCT || COMPILE_TEST
> -	depends on BPF_SYSCALL

[Severity: High]
Does removing this dependency break the build when CONFIG_BPF is disabled?

In the top-level Makefile, the target to prepare tools/bpf/resolve_btfids
is guarded by ifdef CONFIG_BPF. However, scripts/Makefile.vmlinux
unconditionally depends on $(RESOLVE_BTFIDS) when CONFIG_DEBUG_INFO_BTF
is set.

When compiled with CONFIG_DEBUG_INFO_BTF=y and CONFIG_BPF=n, Kbuild falls
back to the tools/% rule, trying to run:
make -C tools/ bpf/resolve_btfids/resolve_btfids

This causes mkdir to create a directory in its place, and make subsequently
fails due to the missing Makefile.

[Severity: Medium]
If CONFIG_BPF is disabled, does this prevent the BTF sysfs interface
from being created?

The commit message mentions that BTF is useful for introspection tools
without the BPF syscall. However, kernel/bpf/sysfs_btf.c provides the
/sys/kernel/btf/vmlinux interface used by these tools.

In kernel/Makefile:
    obj-$(CONFIG_BPF) += bpf/

Since Kbuild only descends into kernel/bpf/ if CONFIG_BPF is enabled,
sysfs_btf.c is silently skipped when CONFIG_BPF=n, hiding the BTF data
from userspace tools.

[Severity: High]
Can this cause a link-time error for bpf_log()?

In net/netfilter/Makefile:
    nf_conntrack-$(CONFIG_DEBUG_INFO_BTF) += nf_conntrack_bpf.o

If CONFIG_DEBUG_INFO_BTF=y and CONFIG_BPF_SYSCALL=n, nf_conntrack_bpf.c
is still compiled. It calls bpf_log() in _nf_conntrack_btf_struct_access().

However, bpf_log() is defined in kernel/bpf/log.c, which is only built if
CONFIG_BPF_SYSCALL=y. Since there is no inline stub for bpf_log() when the
syscall is disabled, this results in an undefined reference to bpf_log
linker error.

[Severity: Low]
Does this result in dead code being compiled in network/netfilter helpers?

Similar to the issue above, files like nf_nat_bpf.c and nf_flow_table_bpf.c
are built conditionally on CONFIG_DEBUG_INFO_BTF in net/netfilter/Makefile.

Without the BPF syscall, register_btf_kfunc_id_set() falls back to an
empty stub, meaning these files compile successfully but provide no
functional value, only increasing kernel size and compilation time.

>  	depends on PAHOLE_VERSION >= 122
>  	# pahole uses elfutils, which does not have support for Hexagon relocations
>  	depends on !HEXAGON

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1