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: 23+ 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
2026-05-15 12:15 ` [PATCH bpf-next v11 00/11] selftests/bpf: Tolerate partial builds across kernel configs Ricardo B. Marlière
2026-05-17 1:32 ` Alexei Starovoitov
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.