* Re: [PATCH bpf-next v11 05/11] selftests/bpf: Make skeleton headers order-only prerequisites of .test.d
[not found] ` <20260430162921.0829BC2BCB3@smtp.kernel.org>
@ 2026-05-04 11:10 ` Ricardo B. Marlière
0 siblings, 0 replies; only message in thread
From: Ricardo B. Marlière @ 2026-05-04 11:10 UTC (permalink / raw)
To: sashiko, Ricardo B. Marlière; +Cc: bpf
Addressed in https://lore.kernel.org/all/DI6KY4J2N2UB.39XQW4ZLTT1VV@suse.com
On Thu Apr 30, 2026 at 1:29 PM -03, sashiko-bot wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Making BPF skeletons order-only prerequisites of `.test.d` prevents the generation of newly added skeletons when they are included via existing local headers, breaking the build.
> --
>
> commit c609958fbea63ac5aab9bea46f3e2a6881af6a94
> Author: Ricardo B. Marlière <rbm@suse.com>
>
> selftests/bpf: Make skeleton headers order-only prerequisites of .test.d
>
> This commit changes the Makefile to make BPF skeleton headers order-only
> prerequisites for .test.d files to prevent unnecessary recompilation. The
> BPF object file is kept as a normal prerequisite.
>
>> 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.
>
> Is this assumption about GNU Make accurate? According to the GNU Make manual,
> order-only prerequisites are never checked when determining if the target is
> out of date.
>
> If a new BPF skeleton is added and included via an existing local header,
> the normal prerequisites of .test.d remain unchanged. Make will consider
> .test.d up to date, skipping the order-only prerequisites entirely.
>
>> 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)
>
> Could this break incremental builds? The old .d file would still track the
> dependency on the modified local header, causing .test.o to be correctly
> identified as out of date.
>
> When Make runs the compiler for .test.o, will it fail immediately with a
> missing file error because the new skeleton was never generated?
>
> Furthermore, if a subsequent patch tolerates test file compilation failures,
> would this result in tests being silently skipped?
^ permalink raw reply [flat|nested] only message in thread