> 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
