From: "Ricardo B. Marlière" <rbm@suse.com>
To: sashiko@lists.linux.dev, "Ricardo B. Marlière" <rbm@suse.com>
Cc: <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next v11 05/11] selftests/bpf: Make skeleton headers order-only prerequisites of .test.d
Date: Mon, 04 May 2026 08:10:34 -0300 [thread overview]
Message-ID: <DI9UHCRWR7LE.13J5GTVBCCDZ8@suse.com> (raw)
In-Reply-To: <20260430162921.0829BC2BCB3@smtp.kernel.org>
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?
next prev parent reply other threads:[~2026-05-04 11:10 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-30 16:02 [PATCH bpf-next v11 00/11] selftests/bpf: Tolerate partial builds across kernel configs Ricardo B. Marlière
2026-04-30 16:02 ` [PATCH bpf-next v11 01/11] selftests/bpf: Add BPF_STRICT_BUILD toggle Ricardo B. Marlière
2026-04-30 16:41 ` bot+bpf-ci
2026-05-04 14:05 ` Ricardo B. Marlière
2026-04-30 16:02 ` [PATCH bpf-next v11 02/11] selftests/bpf: Fix test_kmods KDIR to honor O= and distro kernels Ricardo B. Marlière
2026-04-30 16:42 ` bot+bpf-ci
2026-05-04 14:05 ` Ricardo B. Marlière
2026-04-30 16:02 ` [PATCH bpf-next v11 03/11] selftests/bpf: Tolerate BPF and skeleton generation failures Ricardo B. Marlière
2026-04-30 16:02 ` [PATCH bpf-next v11 04/11] selftests/bpf: Avoid rebuilds when running emit_tests Ricardo B. Marlière
2026-04-30 16:02 ` [PATCH bpf-next v11 05/11] selftests/bpf: Make skeleton headers order-only prerequisites of .test.d Ricardo B. Marlière
2026-04-30 16:29 ` sashiko-bot
2026-05-04 11:10 ` Ricardo B. Marlière [this message]
2026-04-30 16:41 ` bot+bpf-ci
2026-04-30 16:02 ` [PATCH bpf-next v11 06/11] selftests/bpf: Tolerate test file compilation failures Ricardo B. Marlière
2026-04-30 16:02 ` [PATCH bpf-next v11 07/11] selftests/bpf: Skip tests whose objects were not built Ricardo B. Marlière
2026-04-30 16:02 ` [PATCH bpf-next v11 08/11] selftests/bpf: Allow test_progs to link with a partial object set Ricardo B. Marlière
2026-04-30 16:02 ` [PATCH bpf-next v11 09/11] selftests/bpf: Tolerate benchmark build failures Ricardo B. Marlière
2026-04-30 16:38 ` sashiko-bot
2026-05-04 14:04 ` Ricardo B. Marlière
2026-04-30 16:02 ` [PATCH bpf-next v11 10/11] selftests/bpf: Provide weak definitions for cross-test functions Ricardo B. Marlière
2026-04-30 16:02 ` [PATCH bpf-next v11 11/11] selftests/bpf: Tolerate missing files during install Ricardo B. Marlière
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DI9UHCRWR7LE.13J5GTVBCCDZ8@suse.com \
--to=rbm@suse.com \
--cc=bpf@vger.kernel.org \
--cc=sashiko@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox