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

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

[Ricardo B. Marlière]

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?