Re: [PATCH bpf-next v11 02/11] selftests/bpf: Fix test_kmods KDIR to honor O= and distro kernels

[bot+bpf-ci]

> 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 bot+bpf-ci@xxxxxxxxxx and
sashiko-bot@xxxxxxxxxx:

  "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/d1297f1c857e5430af42dcb3e4d05c7ddaff08470a43893cac0fbcb83ec51666@xxxxxxxxxxxxxxx/

[ ... ]


---
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