Re: [PATCH bpf-next v10 05/11] selftests/bpf: Make skeleton headers order-only prerequisites of .test.d

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Changing BPF skeletons to order-only prerequisites of `.test.d` can cause test files to compile against stale `.skel.h` files or fail to compile entirely.
- [Medium] The commit message's justification for keeping `$(BPFOBJ)` as a normal prerequisite relies on a factual misunderstanding of GNU Make semantics.
--

commit 8d292a14fcd0b996b2eefecd2620dba48edb8cd2
Author: Ricardo B. Marlière <rbm@suse.com>

selftests/bpf: Make skeleton headers order-only prerequisites of .test.d

This commit moves the BPF skeleton dependencies to be order-only prerequisites
for the generated .test.d files. It intends to prevent build failures when
skeletons are intentionally skipped.

> $$(BPFOBJ) is intentionally kept as a normal prerequisite: a libbpf
> rebuild legitimately invalidates .test.d, since libbpf header changes
> can affect the headers .test.o sees. Only the skeleton headers are
> moved to order-only.

Does updating .test.d actually force .test.o to rebuild?

In the current Makefile structure, .test.d is attached as an order-only
prerequisite to .test.o. In GNU Make, an order-only prerequisite being
updated does not force its dependent targets to rebuild.

It seems .test.o actually rebuilds upon libbpf changes because GCC's
-MMD flag dynamically embeds explicit paths to the libbpf headers as
normal prerequisites inside the .d file itself, rather than relying on
.test.d invalidation.

> Note that adding a new BPF skeleton via a modified existing local header
> still works correctly: GNU make builds order-only prerequisites that do
> not exist (the order-only qualifier only suppresses timestamp-driven
> rebuilds, not existence-driven builds), so a brand-new .skel.h listed in
> TRUNNER_BPF_SKELS is generated even when .test.d is otherwise up to date.

Will GNU Make actually build the order-only prerequisites if the target
itself is already up to date?

If a local header is modified, .test.d is not considered out of date
because it only depends on the .c file and global headers. If the target
(.test.d) does not need to be rebuilt, Make does not evaluate or build
its order-only prerequisites at all.

> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> index 9a4d8bea0c184..608e6dff03926 100644
> --- a/tools/testing/selftests/bpf/Makefile
> +++ b/tools/testing/selftests/bpf/Makefile
> @@ -726,11 +726,11 @@ $(TRUNNER_TEST_OBJS): $(TRUNNER_OUTPUT)/%.test.o:			\
>  $(TRUNNER_TEST_OBJS:.o=.d): $(TRUNNER_OUTPUT)/%.test.d:			\
>  			    $(TRUNNER_TESTS_DIR)/%.c			\
>  			    $(TRUNNER_EXTRA_HDRS)			\
> +			    $$(BPFOBJ) | $(TRUNNER_OUTPUT)		\
>  			    $(TRUNNER_BPF_SKELS)			\
>  			    $(TRUNNER_BPF_LSKELS)			\
>  			    $(TRUNNER_BPF_LSKELS_SIGNED)		\
> -			    $(TRUNNER_BPF_SKELS_LINKED)			\
> -			    $$(BPFOBJ) | $(TRUNNER_OUTPUT)
> +			    $(TRUNNER_BPF_SKELS_LINKED)

Can this regression cause test files to compile against stale skeleton
headers or fail to compile entirely?

If a developer modifies an existing local header to include a new skeleton
header, the .test.o file is considered out of date because its previously
generated .d file tracks the local header. However, the .test.d target
does not track the local header, so Make considers it up to date.

Because .test.d is up to date, Make skips evaluating its order-only
prerequisites (the skeletons). Make then proceeds to build .test.o before
the new skeleton is generated, leading to either a compilation failure or
a silent build corruption where the test runs against a stale BPF object.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260430-selftests-bpf_misconfig-v10-0-cd302a31af16@suse.com?part=5