From: "Ricardo B. Marlière" <rbm@suse.com>
To: <bot+bpf-ci@kernel.org>, <rbm@suse.com>, <ast@kernel.org>,
<daniel@iogearbox.net>, <andrii@kernel.org>,
<martin.lau@linux.dev>, <eddyz87@gmail.com>, <memxor@gmail.com>,
<song@kernel.org>, <yonghong.song@linux.dev>, <jolsa@kernel.org>,
<shuah@kernel.org>, <nathan@kernel.org>,
<nick.desaulniers+lkml@gmail.com>, <morbo@google.com>,
<justinstitt@google.com>
Cc: <bpf@vger.kernel.org>, <linux-kselftest@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <llvm@lists.linux.dev>,
<alan.maguire@oracle.com>, <martin.lau@kernel.org>,
<clm@meta.com>, <ihor.solodrai@linux.dev>
Subject: Re: [PATCH bpf-next v10 05/11] selftests/bpf: Make skeleton headers order-only prerequisites of .test.d
Date: Thu, 30 Apr 2026 12:04:18 -0300 [thread overview]
Message-ID: <DI6KY4J2N2UB.39XQW4ZLTT1VV@suse.com> (raw)
In-Reply-To: <4de9eeb57c344c41536f55d67f71254eb43687505ecf15f6c4995d73a8fe49c5@mail.kernel.org>
On Thu Apr 30, 2026 at 10:30 AM -03, bot+bpf-ci wrote:
>> 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)
>
> sashiko-bot raised concerns in v9 about the assumption regarding GNU
> Make's behavior with order-only prerequisites. The commit message claims
> that "GNU make builds order-only prerequisites that do not exist," but is
> this correct in the scenario described?
>
> If .test.d already exists and its regular prerequisites are not newer, Make
> ignores order-only prerequisites completely. Since the generated .d files
> only declare dependencies for .test.o and not for .test.d itself, modifying
> a local header to include a new skeleton doesn't mark .test.d as out-of-date.
Alright so this seems to be false. A small counter example below
(disclaimer: also LLM output).
/tmp/oo.mk:
# Reproduces the bot's exact scenario from tools/testing/selftests/bpf:
# .test.o : .c | .test.d (existing rule)
# .test.d : .c | <skel headers> (this patch's change)
# Setup mimics a previous build: .test.o, .test.d, the .c file, and a
# local header all exist on disk; the .d already records that .test.o
# depends on the local header (this is what gcc -MMD captured during the
# previous compile). The local header is then touched -- as if a
# developer had just added a new #include to it -- so .test.o becomes
# timestamp-out-of-date. Crucially, .test.d's own normal prereqs (just
# .c) have NOT been touched, so .test.d is itself "up-to-date": this is
# the bot's exact precondition. A new .skel.h is listed in the
# order-only chain but does not exist on disk yet. The bot claims make
# will silently skip building it. Below shows make builds it anyway.
$(shell rm -rf /tmp/oo; mkdir -p /tmp/oo; \
touch /tmp/oo/foo.c /tmp/oo/local.h; \
printf '%s\n' '/tmp/oo/foo.test.o: /tmp/oo/foo.c /tmp/oo/local.h' \
> /tmp/oo/foo.test.d; \
touch /tmp/oo/foo.test.o; \
sleep 0.1; \
touch /tmp/oo/local.h)
-include /tmp/oo/foo.test.d
/tmp/oo/foo.test.o: /tmp/oo/foo.c | /tmp/oo/foo.test.d
@cat /tmp/oo/new.skel.h >/dev/null && touch $@
@echo " TEST-OBJ $@"
/tmp/oo/foo.test.d: /tmp/oo/foo.c | /tmp/oo/new.skel.h
/tmp/oo/new.skel.h:
@echo "/* generated */" > $@
@echo " GEN-SKEL $@"
Then run it:
$ make -f /tmp/oo.mk /tmp/oo/foo.test.o
GEN-SKEL /tmp/oo/new.skel.h
TEST-OBJ /tmp/oo/foo.test.o
If the order-only chain were skipped at the up-to-date /tmp/oo/foo.test.d,
then /tmp/oo/new.skel.h would never be created, the recipe's cat would fail
with "No such file or directory", and make would abort with Error 1 instead
of relinking /tmp/oo/foo.test.o -- the same failure mode hypothesised for
the real .test.o case. That does not happen.
>
> Could this introduce a race condition or build failures for newly added BPF
> skeletons? The new skeleton might not be generated before compilation, causing
> a missing file error when building .test.o.
>
> Additionally, if the new skeleton is concurrently being generated for another
> test that correctly tracks it, Make won't enforce dependency ordering for the
> modified test. This could result in gcc reading a partially written .skel.h
> file.
With this patch every .test.d entry treats skel headers as order-only, so
there is no "test that does correctly track it" to race against -- the
premise does not hold.
>
> This concern from v9 was not addressed in v10.
>
> Reference: https://lore.kernel.org/bpf/20260429202343.CB842C2BCFA@smtp.kernel.org/
> Reviewer: sashiko-bot@kernel.org
> Date: Wed, 29 Apr 2026 20:23:42 +0000
>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/25167006036
next prev parent reply other threads:[~2026-04-30 15:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-30 12:53 [PATCH bpf-next v10 00/11] selftests/bpf: Tolerate partial builds across kernel configs Ricardo B. Marlière
2026-04-30 12:53 ` [PATCH bpf-next v10 01/11] selftests/bpf: Add BPF_STRICT_BUILD toggle Ricardo B. Marlière
2026-04-30 12:53 ` [PATCH bpf-next v10 02/11] selftests/bpf: Fix test_kmods KDIR to honor O= and distro kernels Ricardo B. Marlière
2026-04-30 13:30 ` bot+bpf-ci
2026-04-30 14:09 ` Ricardo B. Marlière
2026-04-30 12:53 ` [PATCH bpf-next v10 03/11] selftests/bpf: Tolerate BPF and skeleton generation failures Ricardo B. Marlière
2026-04-30 12:53 ` [PATCH bpf-next v10 04/11] selftests/bpf: Avoid rebuilds when running emit_tests Ricardo B. Marlière
2026-04-30 12:53 ` [PATCH bpf-next v10 05/11] selftests/bpf: Make skeleton headers order-only prerequisites of .test.d Ricardo B. Marlière
2026-04-30 13:30 ` bot+bpf-ci
2026-04-30 15:04 ` Ricardo B. Marlière [this message]
2026-04-30 12:53 ` [PATCH bpf-next v10 06/11] selftests/bpf: Tolerate test file compilation failures Ricardo B. Marlière
2026-04-30 13:30 ` bot+bpf-ci
2026-04-30 12:53 ` [PATCH bpf-next v10 07/11] selftests/bpf: Skip tests whose objects were not built Ricardo B. Marlière
2026-04-30 13:30 ` bot+bpf-ci
2026-04-30 15:52 ` Ricardo B. Marlière
2026-04-30 12:53 ` [PATCH bpf-next v10 08/11] selftests/bpf: Allow test_progs to link with a partial object set Ricardo B. Marlière
2026-04-30 12:53 ` [PATCH bpf-next v10 09/11] selftests/bpf: Tolerate benchmark build failures Ricardo B. Marlière
2026-04-30 12:53 ` [PATCH bpf-next v10 10/11] selftests/bpf: Provide weak definitions for cross-test functions Ricardo B. Marlière
2026-04-30 13:30 ` bot+bpf-ci
2026-04-30 12:53 ` [PATCH bpf-next v10 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=DI6KY4J2N2UB.39XQW4ZLTT1VV@suse.com \
--to=rbm@suse.com \
--cc=alan.maguire@oracle.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bot+bpf-ci@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=clm@meta.com \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=ihor.solodrai@linux.dev \
--cc=jolsa@kernel.org \
--cc=justinstitt@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=martin.lau@kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=shuah@kernel.org \
--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