Addressed in https://lore.kernel.org/bpf/[email protected]/
On Thu Apr 30, 2026 at 1:42 PM -03, bot+bpf-ci wrote: >> diff --git a/tools/testing/selftests/bpf/Makefile >> b/tools/testing/selftests/bpf/Makefile >> index 6094fe99b5f6..cc6ee7a2df93 100644 >> --- a/tools/testing/selftests/bpf/Makefile >> +++ b/tools/testing/selftests/bpf/Makefile > > [ ... ] > >> diff --git a/tools/testing/selftests/bpf/test_kmods/Makefile >> b/tools/testing/selftests/bpf/test_kmods/Makefile >> index 63c4d3f6a12f..031c7454ce65 100644 >> --- a/tools/testing/selftests/bpf/test_kmods/Makefile >> +++ b/tools/testing/selftests/bpf/test_kmods/Makefile >> @@ -1,5 +1,16 @@ >> TEST_KMOD_DIR := $(realpath $(dir $(abspath $(lastword $(MAKEFILE_LIST))))) >> -KDIR ?= $(abspath $(TEST_KMOD_DIR)/../../../../..) >> +SRCTREE_KDIR := $(abspath $(TEST_KMOD_DIR)/../../../../..) >> +# Honor O=/KBUILD_OUTPUT only if they point at a prepared kernel build >> +# directory (one containing Module.symvers); otherwise treat the value as a >> +# selftests-only output directory and fall back to in-tree or distro >> headers. >> +# The parent bpf/Makefile resolves O=/KBUILD_OUTPUT to absolute paths before >> +# invoking this sub-make so relative paths still anchor to the user's >> +# invocation directory. >> +KMOD_O := $(or $(O),$(KBUILD_OUTPUT)) >> +KMOD_O_VALID := $(if $(KMOD_O),$(if $(wildcard >> $(KMOD_O)/Module.symvers),$(KMOD_O))) >> +KDIR ?= $(if $(KMOD_O_VALID),$(SRCTREE_KDIR), \ >> + $(if $(wildcard $(SRCTREE_KDIR)/Module.symvers),$(SRCTREE_KDIR), \ >> + /lib/modules/$(shell uname -r)/build)) > > Will the automatic fallback to /lib/modules/$(uname -r)/build cause > confusing build failures? > > Since bpf_testmod relies heavily on internal BPF structures, experimental > macros, and kfuncs that change frequently between kernel releases, compiling > it against host distro headers on a system where the running kernel does not > match the upstream source tree will likely fail. > > If the host headers are present, the permissive skip check further down in > the file will pass since the directory exists. However, because the > compilation failure is not ignored by the parent bpf/Makefile, this would > abort the entire BPF selftests build with confusing C compilation errors > instead of silently skipping the unconfigured kernel tree. > > Should in-tree test modules avoid falling back to host distro headers to > prevent these version mismatches? > > This concern was raised in v9 and v10 by [email protected] and > [email protected]: > > "Will falling back to the host kernel headers cause compilation errors > when building in-tree test modules like bpf_testmod? Since bpf_testmod > relies heavily on internal BPF structures, experimental macros, and > kfuncs that change frequently between kernel releases, compiling it > against /lib/modules/$(uname -r)/build on a system where the running > kernel does not exactly match the upstream source tree will likely fail. > If the host headers are present, the permissive skip check further down > in the file will pass since the directory exists. Because the compilation > failure is not ignored by the parent bpf/Makefile, won't this abort the > entire BPF selftests build with confusing C compilation errors instead of > silently skipping the unconfigured kernel tree? Should in-tree test > modules avoid falling back to host distro headers to prevent these > version mismatches?" > > Reference: > https://lore.kernel.org/bpf/d1297f1c857e5430af42dcb3e4d05c7ddaff08470a43893cac0fbcb83ec51...@mail.kernel.org/ > > [ ... ] > > > --- > AI reviewed your patch. Please fix the bug or email reply why it's not a bug. > See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md > > CI run summary: https://github.com/kernel-patches/bpf/actions/runs/25176431268
