From: sashiko-bot@kernel.org
To: "Ricardo B. Marlière" <rbm@suse.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v9 05/11] selftests/bpf: Make skeleton headers order-only prerequisites of .test.d
Date: Wed, 29 Apr 2026 20:23:42 +0000 [thread overview]
Message-ID: <20260429202343.CB842C2BCFA@smtp.kernel.org> (raw)
In-Reply-To: <20260429-selftests-bpf_misconfig-v9-5-c311f06b4791@suse.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Moving skeleton headers to order-only prerequisites breaks incremental builds and introduces a race condition for newly added BPF skeletons.
--
commit ac3be1ba89ba94d2363d76ee3f21b9f53e47cc23
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 skeleton headers order-only
prerequisites of .test.d files. It aims to avoid unnecessary recompilation
and build errors when a skeleton is skipped due to BPF compilation failure.
> 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's behavior correct?
If a target like .test.d already exists and its regular prerequisites are not
newer, Make ignores its order-only prerequisites completely. Because the
generated .d files only declare dependencies for .test.o and not for .test.d,
modifying a local header to include a new skeleton does not mark .test.d as
out-of-date.
> 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)
Does this introduce a race condition or build failures for newly added BPF
skeletons?
Since the new skeleton is not generated before compilation in the scenario
described above, it could cause a missing file error when building .test.o.
Furthermore, if the new skeleton is concurrently being generated for another
test that does correctly track it, Make will not enforce dependency ordering
for the modified test. This could result in gcc reading a partially written
.skel.h file.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260429-selftests-bpf_misconfig-v9-0-c311f06b4791@suse.com?part=5
next prev parent reply other threads:[~2026-04-29 20:23 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-29 14:33 [PATCH bpf-next v9 00/11] selftests/bpf: Tolerate partial builds across kernel configs Ricardo B. Marlière
2026-04-29 14:33 ` [PATCH bpf-next v9 01/11] selftests/bpf: Add BPF_STRICT_BUILD toggle Ricardo B. Marlière
2026-04-29 15:13 ` bot+bpf-ci
2026-04-29 16:03 ` Ricardo B. Marlière
2026-04-29 14:33 ` [PATCH bpf-next v9 02/11] selftests/bpf: Fix test_kmods KDIR to honor O= and distro kernels Ricardo B. Marlière
2026-04-29 19:41 ` sashiko-bot
2026-04-29 14:33 ` [PATCH bpf-next v9 03/11] selftests/bpf: Tolerate BPF and skeleton generation failures Ricardo B. Marlière
2026-04-29 15:13 ` bot+bpf-ci
2026-04-29 16:03 ` Ricardo B. Marlière
2026-04-29 14:33 ` [PATCH bpf-next v9 04/11] selftests/bpf: Avoid rebuilds when running emit_tests Ricardo B. Marlière
2026-04-29 14:33 ` [PATCH bpf-next v9 05/11] selftests/bpf: Make skeleton headers order-only prerequisites of .test.d Ricardo B. Marlière
2026-04-29 20:23 ` sashiko-bot [this message]
2026-04-29 14:33 ` [PATCH bpf-next v9 06/11] selftests/bpf: Tolerate test file compilation failures Ricardo B. Marlière
2026-04-29 20:37 ` sashiko-bot
2026-04-29 14:33 ` [PATCH bpf-next v9 07/11] selftests/bpf: Skip tests whose objects were not built Ricardo B. Marlière
2026-04-29 14:33 ` [PATCH bpf-next v9 08/11] selftests/bpf: Allow test_progs to link with a partial object set Ricardo B. Marlière
2026-04-29 14:33 ` [PATCH bpf-next v9 09/11] selftests/bpf: Tolerate benchmark build failures Ricardo B. Marlière
2026-04-29 21:08 ` sashiko-bot
2026-04-29 14:33 ` [PATCH bpf-next v9 10/11] selftests/bpf: Provide weak definitions for cross-test functions Ricardo B. Marlière
2026-04-29 21:29 ` sashiko-bot
2026-04-29 14:33 ` [PATCH bpf-next v9 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=20260429202343.CB842C2BCFA@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=rbm@suse.com \
--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