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

["Ricardo B. Marlière" <rbm@suse.com>]

Addressed in https://lore.kernel.org/bpf/DI6JRYWASEYN.3I8Q81ZPUE1VE@suse.com/

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 bot+bpf-ci@kernel.org and
> sashiko-bot@kernel.org:
>
>   "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@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