On Thu Apr 30, 2026 at 10:30 AM -03, bot+bpf-ci wrote:
>> 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.
Alright so this seems to be false. A small counter example below
(disclaimer: also LLM output).
/tmp/oo.mk:
# Reproduces the bot's exact scenario from tools/testing/selftests/bpf:
# .test.o : .c | .test.d (existing rule)
# .test.d : .c | <skel headers> (this patch's change)
# Setup mimics a previous build: .test.o, .test.d, the .c file, and a
# local header all exist on disk; the .d already records that .test.o
# depends on the local header (this is what gcc -MMD captured during the
# previous compile). The local header is then touched -- as if a
# developer had just added a new #include to it -- so .test.o becomes
# timestamp-out-of-date. Crucially, .test.d's own normal prereqs (just
# .c) have NOT been touched, so .test.d is itself "up-to-date": this is
# the bot's exact precondition. A new .skel.h is listed in the
# order-only chain but does not exist on disk yet. The bot claims make
# will silently skip building it. Below shows make builds it anyway.
$(shell rm -rf /tmp/oo; mkdir -p /tmp/oo; \
touch /tmp/oo/foo.c /tmp/oo/local.h; \
printf '%s\n' '/tmp/oo/foo.test.o: /tmp/oo/foo.c /tmp/oo/local.h' \
> /tmp/oo/foo.test.d; \
touch /tmp/oo/foo.test.o; \
sleep 0.1; \
touch /tmp/oo/local.h)
-include /tmp/oo/foo.test.d
/tmp/oo/foo.test.o: /tmp/oo/foo.c | /tmp/oo/foo.test.d
@cat /tmp/oo/new.skel.h >/dev/null && touch $@
@echo " TEST-OBJ $@"
/tmp/oo/foo.test.d: /tmp/oo/foo.c | /tmp/oo/new.skel.h
/tmp/oo/new.skel.h:
@echo "/* generated */" > $@
@echo " GEN-SKEL $@"
Then run it:
$ make -f /tmp/oo.mk /tmp/oo/foo.test.o
GEN-SKEL /tmp/oo/new.skel.h
TEST-OBJ /tmp/oo/foo.test.o
If the order-only chain were skipped at the up-to-date /tmp/oo/foo.test.d,
then /tmp/oo/new.skel.h would never be created, the recipe's cat would fail
with "No such file or directory", and make would abort with Error 1 instead
of relinking /tmp/oo/foo.test.o -- the same failure mode hypothesised for
the real .test.o case. That does not happen.
>
> 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.
With this patch every .test.d entry treats skel headers as order-only, so
there is no "test that does correctly track it" to race against -- the
premise does not hold.
>
> 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
