From: sashiko-bot@kernel.org
To: "Ricardo B. Marlière" <rbm@suse.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v5 07/11] selftests/bpf: Allow test_progs to link with a partial object set
Date: Wed, 15 Apr 2026 21:19:04 +0000 [thread overview]
Message-ID: <20260415211904.CBCC4C19424@smtp.kernel.org> (raw)
In-Reply-To: <20260415-selftests-bpf_misconfig-v5-7-03d0a52a898a@suse.com>
Sashiko AI review found 2 potential issue(s):
- [Medium] Moving `$(TRUNNER_TEST_OBJS)` to order-only prerequisites silently breaks incremental linking for BPF programs and headers.
- [Medium] Linking with a partial object set introduces a regression that causes the test runner to unconditionally abort at runtime.
--
commit 26b01d6050c56240db40d2043c1d68b4a725414c
Author: Ricardo B. Marlière <rbm@suse.com>
selftests/bpf: Allow test_progs to link with a partial object set
This commit modifies the Makefile to move test objects to the order-only
prerequisite list and uses wildcard expansion to only link built test
objects. This allows the test suite to link even if some test objects
fail to compile.
> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> --- a/tools/testing/selftests/bpf/Makefile
> +++ b/tools/testing/selftests/bpf/Makefile
[ ... ]
> -$(OUTPUT)/$(TRUNNER_BINARY): $(TRUNNER_TEST_OBJS) \
> - $(TRUNNER_EXTRA_OBJS) $$(BPFOBJ) \
> +$(OUTPUT)/$(TRUNNER_BINARY): $(TRUNNER_EXTRA_OBJS) $$(BPFOBJ) \
> $(TRUNNER_LIB_OBJS) \
> $(TRUNNER_BPFTOOL) \
> $(OUTPUT)/veristat \
> - | $(TRUNNER_BINARY)-extras
> + | $(TRUNNER_BINARY)-extras \
> + $(TRUNNER_TEST_OBJS)
Will moving TRUNNER_TEST_OBJS to the order-only prerequisites break
incremental builds?
In GNU Make, order-only prerequisites ensure build order but do not trigger
a rebuild of the target when they are updated.
Modifying a BPF program correctly recompiles the BPF object and the test
object file. However, because TRUNNER_TEST_OBJS is no longer a normal
prerequisite, it appears the binary will not be relinked unless a manual
clean is performed, silently ignoring changes to BPF programs.
> $$(call msg,BINARY,,$$@)
> - $(Q)$$(CC) $$(CFLAGS) $$(filter %.a %.o,$$^) $$(LDLIBS) $$(LLVM_LDLIBS) $$(LDFLAGS) $$(LLVM_LDFLAGS) -o $$@
> + $(Q)$$(CC) $$(CFLAGS) $$(filter %.a %.o,$(if $(PERMISSIVE),$$(wildcard $(TRUNNER_TEST_OBJS)),$(TRUNNER_TEST_OBJS)) $$^) $$(LDLIBS) $$(LLVM_LDLIBS) $$(LDFLAGS) $$(LLVM_LDFLAGS) -o $$@
Does linking with a partial object set cause the test framework to
unconditionally abort at runtime?
The test framework dynamically generates prog_tests/tests.h which expands
into weak symbols in test_progs.c. If a test object is omitted due to a build
failure, its weak symbols correctly resolve to NULL.
During initialization, the test_progs binary iterates over registered tests
and validates that every test has a valid function pointer. It prints an error
and immediately aborts via exit(EXIT_ERR_SETUP_INFRA) if it encounters a NULL
pointer.
While this is addressed later in the series by commit 6ad669628925e
("selftests/bpf: Skip tests whose objects were not built"), does this patch
introduce a temporary break in test infrastructure functionality?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260415-selftests-bpf_misconfig-v5-0-03d0a52a898a@suse.com?part=7
next prev parent reply other threads:[~2026-04-15 21:19 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-15 20:59 [PATCH bpf-next v5 00/11] selftests/bpf: Tolerate partial builds across kernel configs Ricardo B. Marlière
2026-04-15 20:59 ` [PATCH bpf-next v5 01/11] selftests/bpf: Add BPF_STRICT_BUILD toggle Ricardo B. Marlière
2026-04-15 20:59 ` [PATCH bpf-next v5 02/11] selftests/bpf: Fix test_kmods KDIR to honor O= and distro kernels Ricardo B. Marlière
2026-04-15 21:18 ` sashiko-bot
2026-04-15 21:43 ` bot+bpf-ci
2026-04-15 20:59 ` [PATCH bpf-next v5 03/11] selftests/bpf: Tolerate BPF and skeleton generation failures Ricardo B. Marlière
2026-04-15 21:15 ` sashiko-bot
2026-04-15 21:43 ` bot+bpf-ci
2026-04-15 20:59 ` [PATCH bpf-next v5 04/11] selftests/bpf: Avoid rebuilds when running emit_tests Ricardo B. Marlière
2026-04-15 20:59 ` [PATCH bpf-next v5 05/11] selftests/bpf: Make skeleton headers order-only prerequisites of .test.d Ricardo B. Marlière
2026-04-15 20:59 ` [PATCH bpf-next v5 06/11] selftests/bpf: Tolerate test file compilation failures Ricardo B. Marlière
2026-04-15 20:59 ` [PATCH bpf-next v5 07/11] selftests/bpf: Allow test_progs to link with a partial object set Ricardo B. Marlière
2026-04-15 21:19 ` sashiko-bot [this message]
2026-04-15 21:54 ` bot+bpf-ci
2026-04-15 20:59 ` [PATCH bpf-next v5 08/11] selftests/bpf: Tolerate benchmark build failures Ricardo B. Marlière
2026-04-15 20:59 ` [PATCH bpf-next v5 09/11] selftests/bpf: Provide weak definitions for cross-test functions Ricardo B. Marlière
2026-04-15 20:59 ` [PATCH bpf-next v5 10/11] selftests/bpf: Skip tests whose objects were not built Ricardo B. Marlière
2026-04-15 21:11 ` sashiko-bot
2026-04-15 21:43 ` bot+bpf-ci
2026-04-15 20:59 ` [PATCH bpf-next v5 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=20260415211904.CBCC4C19424@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 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.