From: Mykola Lysenko <nickolay.lysenko@gmail.com>
To: bpf@vger.kernel.org
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
eddyz87@gmail.com, martin.lau@linux.dev, song@kernel.org,
yonghong.song@linux.dev, jolsa@kernel.org, memxor@gmail.com,
nickolay.lysenko@gmail.com
Subject: [PATCH bpf-next v7 4/9] selftests/bpf: generate the signing key and certificate once
Date: Sun, 23 Aug 2026 12:42:36 -0700 [thread overview]
Message-ID: <20260823194241.3415152-5-nickolay.lysenko@gmail.com> (raw)
In-Reply-To: <20260823194241.3415152-1-nickolay.lysenko@gmail.com>
$(VERIFICATION_CERT) and $(PRIVATE_KEY) come from a single genkey
invocation, but a rule with two normal targets runs its recipe once
per stale target. Today only $(VERIFICATION_CERT) is ever a
prerequisite (of $(VERIFY_SIG_HDR)), so the recipe runs once; the
runner patch later in this series lists both files as prerequisites
of the same target, at which point both runs would execute, under -j
concurrently, and the openssl invocations would race on the same
output files.
Rewrite it as a pattern rule, the same workaround the test_kmods
rule already uses, with the stem narrowed to the fixed name: genkey
hardcodes signing_key.pem / signing_key.der, and a wider pattern
would claim every .pem/.der under $(BUILD_DIR) and "succeed" without
producing the requested file.
Signed-off-by: Mykola Lysenko <nickolay.lysenko@gmail.com>
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
---
tools/testing/selftests/bpf/Makefile | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index e4c8efd1e6f1..7b80a1b1ef76 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -787,7 +787,12 @@ VERIFY_SIG_HDR := verification_cert.h
VERIFICATION_CERT := $(BUILD_DIR)/signing_key.der
PRIVATE_KEY := $(BUILD_DIR)/signing_key.pem
-$(VERIFICATION_CERT) $(PRIVATE_KEY): $(VERIFY_SIG_SETUP)
+# One genkey run produces both files. A plain two-target rule is not
+# grouped - if both files are stale make would run genkey twice, under
+# -j concurrently, and the openssl invocations race; the pattern form
+# is implicitly grouped even with make < 4.3. The stem only stands in
+# for 'signing' so that no other .pem/.der under $(BUILD_DIR) matches.
+$(BUILD_DIR)/%_key.pem $(BUILD_DIR)/%_key.der: $(VERIFY_SIG_SETUP)
$(Q)mkdir -p $(BUILD_DIR)
$(Q)$(VERIFY_SIG_SETUP) genkey $(BUILD_DIR)
--
2.43.0
next prev parent reply other threads:[~2026-08-23 19:43 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-23 19:42 [PATCH bpf-next v7 0/9] selftests/bpf: restructure the Makefile as a layered build Mykola Lysenko
2026-08-23 19:42 ` [PATCH bpf-next v7 1/9] selftests/bpf: keep headers off the generic link command line Mykola Lysenko
2026-08-23 19:42 ` [PATCH bpf-next v7 2/9] selftests/bpf: drop stale lines, restore two header dependencies Mykola Lysenko
2026-08-23 20:41 ` bot+bpf-ci
2026-08-24 22:47 ` Eduard Zingerman
2026-08-23 19:42 ` [PATCH bpf-next v7 3/9] selftests/bpf: factor the permissive-mode skip suffix into a helper Mykola Lysenko
2026-08-23 19:51 ` sashiko-bot
2026-08-23 19:42 ` Mykola Lysenko [this message]
2026-08-23 19:42 ` [PATCH bpf-next v7 5/9] selftests/bpf: generate verifier/tests.h in a regular recipe Mykola Lysenko
2026-08-23 19:42 ` [PATCH bpf-next v7 6/9] selftests/bpf: derive the bench object list from the sources Mykola Lysenko
2026-08-24 23:42 ` Eduard Zingerman
2026-08-23 19:42 ` [PATCH bpf-next v7 7/9] selftests/bpf: extract BPF skeleton generation into a helper script Mykola Lysenko
2026-08-23 19:42 ` [PATCH bpf-next v7 8/9] selftests/bpf: move shared build definitions into Makefile.buildvars Mykola Lysenko
2026-08-23 20:53 ` bot+bpf-ci
2026-08-25 6:45 ` Eduard Zingerman
2026-08-23 19:42 ` [PATCH bpf-next v7 9/9] selftests/bpf: build each test runner instance in its own sub-make Mykola Lysenko
2026-08-23 21:05 ` bot+bpf-ci
2026-08-25 23:55 ` Eduard Zingerman
2026-08-26 4:58 ` Eduard Zingerman
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=20260823194241.3415152-5-nickolay.lysenko@gmail.com \
--to=nickolay.lysenko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=jolsa@kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=song@kernel.org \
--cc=yonghong.song@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