> diff --git a/tools/testing/selftests/bpf/Makefile 
> b/tools/testing/selftests/bpf/Makefile
> index 9a4d8bea0c18..608e6dff0392 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)

sashiko-bot raised concerns in v9 about the assumption regarding GNU
Make's behavior with order-only prerequisites. The commit message claims
that "GNU make builds order-only prerequisites that do not exist," but is
this correct in the scenario described?

If .test.d already exists and its regular prerequisites are not newer, Make
ignores order-only prerequisites completely. Since the generated .d files
only declare dependencies for .test.o and not for .test.d itself, modifying
a local header to include a new skeleton doesn't mark .test.d as out-of-date.

Could this introduce a race condition or build failures for newly added BPF
skeletons? The new skeleton might not be generated before compilation, causing
a missing file error when building .test.o.

Additionally, if the new skeleton is concurrently being generated for another
test that correctly tracks it, Make won't enforce dependency ordering for the
modified test. This could result in gcc reading a partially written .skel.h
file.

This concern from v9 was not addressed in v10.

Reference: 
https://lore.kernel.org/bpf/[email protected]/
Reviewer: [email protected]
Date: Wed, 29 Apr 2026 20:23:42 +0000


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

Reply via email to