From: Eduard Zingerman <eddyz87@gmail.com>
To: HyeongJun An <sammiee5311@gmail.com>, bpf@vger.kernel.org
Cc: "Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Martin KaFai Lau" <martin.lau@linux.dev>,
"Ricardo B . Marlière" <rbm@suse.com>,
"Emil Tsalapatis" <emil@etsalapatis.com>,
"Mykola Lysenko" <nickolay.lysenko@gmail.com>,
"Shuah Khan" <shuah@kernel.org>,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next] selftests/bpf: Tolerate libarena skeleton failures under BPF_STRICT_BUILD=0
Date: Fri, 11 Sep 2026 13:24:30 -0700 [thread overview]
Message-ID: <c2235ade283e0258e7ab018bafcc99b32a63f586.camel@gmail.com> (raw)
In-Reply-To: <20260911141621.1944900-1-sammiee5311@gmail.com>
On Fri, 2026-09-11 at 23:16 +0900, HyeongJun An wrote:
> The Makefile documents BPF_STRICT_BUILD=0 as tolerating any BPF object,
> skeleton, test object or benchmark failure so that the remaining tests
> still build. Every skeleton rule honours that through
> $(if $(PERMISSIVE),...), except the three that build the libarena
> skeletons. Those invoke a sub-make with no guard, so a libarena failure
> is fatal even in permissive mode.
>
> With a libarena source that fails to compile, BPF_STRICT_BUILD=0 stops at
>
> make: *** [libarena/libarena.skel.h] Error 2
>
> while an ordinary program failing the same way prints SKIP-BPF and the
> build carries on.
>
> Guard the three sub-makes the way the other skeleton rules are guarded.
> The build then prints SKIP-SKEL and continues, and test_progs,
> test_progs-no_alu32, test_progs-cpuv4 and bench all link. Nothing
> downstream needs a change, because the missing skeleton drops out through
> the existing permissive paths and libarena.test.o is reported as
> SKIP-TEST. The default BPF_STRICT_BUILD=1 still fails on the same input.
>
> Fixes: a6850fa388f6 ("selftests/bpf: Add BPF_STRICT_BUILD toggle")
> Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
> Assisted-by: Claude:claude-opus-5
> ---
Why is this change necessary?
The whole PERMISSIVE thing is quite ugly and I regret not being
involved in it's review.
...
next prev parent reply other threads:[~2026-09-11 20:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-11 14:16 [PATCH bpf-next] selftests/bpf: Tolerate libarena skeleton failures under BPF_STRICT_BUILD=0 HyeongJun An
2026-09-11 14:33 ` sashiko-bot
2026-09-11 15:27 ` bot+bpf-ci
2026-09-11 18:02 ` Ricardo B. Marlière (SUSE)
2026-09-12 0:47 ` HyeongJun An
2026-09-11 20:24 ` Eduard Zingerman [this message]
2026-09-12 0:59 ` HyeongJun An
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=c2235ade283e0258e7ab018bafcc99b32a63f586.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=emil@etsalapatis.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=nickolay.lysenko@gmail.com \
--cc=rbm@suse.com \
--cc=sammiee5311@gmail.com \
--cc=shuah@kernel.org \
/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.