From: Paul Chaignon <paul.chaignon@gmail.com>
To: Tiezhu Yang <yangtiezhu@loongson.cn>
Cc: Emil Tsalapatis <emil@etsalapatis.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Hengqi Chen <hengqi.chen@gmail.com>,
loongarch@lists.linux.dev, bpf@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next v1 1/2] selftests/bpf: Check alignment flag if expected result is REJECT
Date: Thu, 12 Mar 2026 10:29:47 +0100 [thread overview]
Message-ID: <abKHi9Pr5iUbIQZI@mail.gmail.com> (raw)
In-Reply-To: <fe04d981-fc83-0ba6-4dee-8fc0c953e09f@loongson.cn>
On Thu, Mar 12, 2026 at 02:59:57PM +0800, Tiezhu Yang wrote:
> Hi Emil and Paul,
Hi Tiezhu,
>
> On 2026/3/11 下午11:56, Emil Tsalapatis wrote:
> > On Tue Mar 10, 2026 at 2:45 AM EDT, Tiezhu Yang wrote:
> > > CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set unconditionally for the
> > > most archs such as x86_64, aarch64, ppc64el and s390x, but this config
> > > may be not set by users for riscv64 and loongarch64.
> > >
> > > If CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is not set, the BPF verifier
> > > detects if a program has unaligned access and then rejects them. So it
> > > should also check the flag F_NEEDS_EFFICIENT_UNALIGNED_ACCESS if the
> > > expected result is REJECT and set alignment_prevented_execution as 1,
> > > then the message "(NOTE: not executed due to unknown alignment)" can
> > > be printed for some testcases of test_verifier to reflect the reality.
> > >
> > > Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
> > > ---
> > > tools/testing/selftests/bpf/test_verifier.c | 5 +++++
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/tools/testing/selftests/bpf/test_verifier.c b/tools/testing/selftests/bpf/test_verifier.c
> > > index a8ae03c57bba..a1ae2f044e96 100644
> > > --- a/tools/testing/selftests/bpf/test_verifier.c
> > > +++ b/tools/testing/selftests/bpf/test_verifier.c
> > > @@ -1640,6 +1640,11 @@ static void do_test_single(struct bpf_test *test, bool unpriv,
> > > printf("FAIL\nUnexpected success to load!\n");
> > > goto fail_log;
> > > }
> > > +#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> > > + if (fd_prog < 0 &&
> > > + (test->flags & F_NEEDS_EFFICIENT_UNALIGNED_ACCESS))
> > > + alignment_prevented_execution = 1;
> > > +#endif
> >
> > This doesn't look like it's breaking anything, but it will cause all
> > tests with F_NEEDS_EFFICIENT_UNALIGNED ACCESS to be reported as failing
> > due to unaligned accesses even if they actually failed due to expected
> > errors at load time.
> >
> > Which test programs is this fix targeted towards? Can't we just skip
> > those tests for riscv/loongarch instead of adding this workaround?
>
> Thanks for your reviews.
>
> It does not fix any failed testcases, the testcases passed without
> and with this patch. It only affects the output for some testcases
> such as test_verifier 14, 153, 190, 191, 193, 197, 200, 201, 202,
> 204, 255, 256, 295, 297, 298, 300, 301, 302, 307, 308, 331, 341,
> 342, 475, 477, 500, 512, 514, 515, 517, 520, 522, 523, 525.
>
> For example, for the test_verifier 14,
> verifier/atomic_cmpxchg.c:215
> "Dest pointer in r0 - succeed, check 5",
> if remove ".flags = F_NEEDS_EFFICIENT_UNALIGNED_ACCESS,",
I think I'm missing something. Why would you remove this flag?
Are you trying to illustrate that this is a program that could be
rejected because of misaligned accesses? I agree, but here the flag is
set and this program is therefore rejected because of an invalid memory
access; the misalgined access check is skipped in the verifier.
> here is the test result if HAVE_EFFICIENT_UNALIGNED_ACCESS is not set:
>
> $ sudo ./test_verifier 14
> #14/u Dest pointer in r0 - succeed, check 5 OK
> #14/p Dest pointer in r0 - succeed, check 5 FAIL
> Unexpected verifier log!
> EXP: R0 invalid mem access
> RES:
> FAIL
> Unexpected error message!
> EXP: R0 invalid mem access
> RES: misaligned access off (0x0; 0xffffffff)+-8 size 4
> verification time 27 usec
> stack depth 8
> processed 5 insns (limit 1000000) max_states_per_insn 0 total_states 0
> peak_states 0 mark_read 0
>
> misaligned access off (0x0; 0xffffffff)+-8 size 4
> verification time 27 usec
> stack depth 8
> processed 5 insns (limit 1000000) max_states_per_insn 0 total_states 0
> peak_states 0 mark_read 0
> Summary: 1 PASSED, 0 SKIPPED, 1 FAILED
>
> It seems that this is because the program has unaligned accesses,
> but the kernel sets CONFIG_ARCH_STRICT_ALIGN by default to enable
> -mstrict-align to prevent unaligned accesses.
>
> So I think add "(NOTE: not executed due to unknown alignment)" to the
> output is reasonable. Something I missed?
>
> Without this patch:
>
> sudo ./test_verifier > log.before
>
> With this patch:
>
> sudo ./test_verifier > log.after
>
> Here is the diff:
>
> $ diff -uNr log.before log.after
> --- log.before 2026-03-12 14:19:04.119957887 +0800
> +++ log.after 2026-03-12 14:23:03.468251328 +0800
> @@ -26,7 +26,7 @@
> #12/p Dest pointer in r0 - succeed, check 3 OK
> #13/u Dest pointer in r0 - succeed, check 4 OK
> #13/p Dest pointer in r0 - succeed, check 4 OK
> -#14/p Dest pointer in r0 - succeed, check 5 OK
> +#14/p Dest pointer in r0 - succeed, check 5 OK (NOTE: not executed due to
> unknown alignment)
As stated in my previous answer, this note would be incorrect: the
program was executed in test case #14 because it was rejected, not
because of unknown alignment.
[...]
next prev parent reply other threads:[~2026-03-12 9:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-10 6:45 [PATCH bpf-next v1 0/2] Modify some code about test_verifier Tiezhu Yang
2026-03-10 6:45 ` [PATCH bpf-next v1 1/2] selftests/bpf: Check alignment flag if expected result is REJECT Tiezhu Yang
2026-03-11 15:56 ` Emil Tsalapatis
2026-03-12 6:59 ` Tiezhu Yang
2026-03-12 9:29 ` Paul Chaignon [this message]
2026-03-12 11:06 ` Tiezhu Yang
2026-03-16 13:04 ` Paul Chaignon
2026-03-17 1:56 ` Tiezhu Yang
2026-03-11 16:11 ` Paul Chaignon
2026-03-10 6:45 ` [PATCH bpf-next v1 2/2] selftests/bpf: Add alignment flag for test_verifier 190 testcase Tiezhu Yang
2026-03-11 15:57 ` Emil Tsalapatis
2026-03-11 16:13 ` Paul Chaignon
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=abKHi9Pr5iUbIQZI@mail.gmail.com \
--to=paul.chaignon@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=emil@etsalapatis.com \
--cc=hengqi.chen@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=yangtiezhu@loongson.cn \
/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.