> diff --git a/tools/testing/selftests/bpf/Makefile > b/tools/testing/selftests/bpf/Makefile > index 75036c1b5c4f..e912526a65dd 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)) Multiple reviewers raised concerns about the automatic fallback to /lib/modules/$(uname -r)/build. bpf_testmod relies heavily on internal BPF structures, experimental macros, and kfuncs that change frequently between kernel releases. When compiling against host distro headers on a system where the running kernel does not match the upstream source tree being tested, will this cause confusing C compilation errors? If the host headers exist, the permissive skip check further down in the Makefile will pass since the directory exists. However, the compilation failure is not ignored by the parent bpf/Makefile, which could abort the entire BPF selftests build with confusing 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 by multiple reviewers (sashiko-bot, bot+bpf-ci) in v9, v10, and v11. You acknowledged it in v10 and stated it's a deliberate design choice inspired by livepatch, but the concern was raised again in v11. Reference: https://lore.kernel.org/bpf/f07336b357836aa0d9b5017f4bdf56969d6cb4044b8df5fd9dc67baf593b7...@mail.kernel.org/ > > ifeq ($(V),1) > Q = [ ... ] --- 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/26821824931
