From: Eduard Zingerman <eddyz87@gmail.com>
To: Paul Chaignon <paul.chaignon@gmail.com>
Cc: bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
Shung-Hsi Yu <shung-hsi.yu@suse.com>
Subject: Re: [PATCH bpf-next v2 3/4] selftests/bpf: Test cross-sign 64bits range refinement
Date: Thu, 24 Jul 2025 16:52:35 -0700 [thread overview]
Message-ID: <6d75ad3a05ebf56ab2f68e677264e8142c372fbc.camel@gmail.com> (raw)
In-Reply-To: <aIKtSK9LjQXB8FLY@mail.gmail.com>
On Fri, 2025-07-25 at 00:01 +0200, Paul Chaignon wrote:
> On Thu, Jul 24, 2025 at 12:15:53PM -0700, Eduard Zingerman wrote:
> > On Thu, 2025-07-24 at 15:43 +0200, Paul Chaignon wrote:
>
> [...]
>
> > > +SEC("socket")
> > > +__description("bounds deduction cross sign boundary, negative overlap")
> > > +__success __log_level(2) __flag(BPF_F_TEST_REG_INVARIANTS)
> > > +__msg("7: (1f) r0 -= r6 {{.*}} R0=scalar(smin=-655,smax=smax32=-146,umin=0xfffffffffffffd71,umax=0xffffffffffffff6e,smin32=-783,umin32=0xfffffcf1,umax32=0xffffff6e,var_off=(0xfffffffffffffc00; 0x3ff))")
> >
> > Interesting, note the difference: smin=-655, smin32=-783.
> > There is a code to infer s32 range from s46 range in this situation in
> > __reg32_deduce_bounds(), but it looks like a third __reg_deduce_bounds
> > call is needed to trigger it. E.g. the following patch removes the
> > difference for me:
>
> Hm, I can add the third __reg_deduce_bounds to the first patch in the
> series. That said, we may want to rethink and optimize reg_bounds_sync
> in a followup patchset. It's probably worth listing all the inferences
> we have and their dependencies and see if we can reorganize the
> subfunctions.
Let's not add third __reg_deduce_bounds yet. After inserting some
prints and looking more closely at the log, something funny happens at
instruction #2:
2: (bc) w6 = (s8)w0
reg_bounds_sync entry: scalar(smin=0,smax=umax=0xffffffff,smin32=-128,smax32=127,var_off=(0x0; 0xffffffff))
reg_bounds_sync __update_reg_bounds #1: scalar(smin=0,smax=umax=0xffffffff,smin32=-128,smax32=127,var_off=(0x0; 0xffffffff))
reg_bounds_sync __reg_deduce_bounds #1: scalar(smin=0,smax=umax=0xffffffff,smin32=-128,smax32=127,var_off=(0x0; 0xffffffff))
reg_bounds_sync __reg_deduce_bounds #2: scalar(smin=0,smax=umax=0xffffffff,smin32=-128,smax32=127,var_off=(0x0; 0xffffffff))
reg_bounds_sync __reg_bound_offset: scalar(smin=0,smax=umax=0xffffffff,smin32=-128,smax32=127,var_off=(0x0; 0xffffffff))
reg_bounds_sync __update_reg_bounds #2: scalar(smin=0,smax=umax=0xffffffff,smin32=-128,smax32=127,var_off=(0x0; 0xffffffff))
3: R0_w=scalar() R6_w=scalar(smin=0,smax=umax=0xffffffff,smin32=-128,smax32=127,var_off=(0x0; 0xffffffff))
It would be good to figure out what happens here.
That being said, the issue is not related to the patch in question.
I suggest rephrasing the test to avoid the sign extension above.
[...]
next prev parent reply other threads:[~2025-07-24 23:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-24 13:41 [PATCH bpf-next v2 0/4] bpf: Improve 64bits bounds refinement Paul Chaignon
2025-07-24 13:42 ` [PATCH bpf-next v2 1/4] bpf: Improve bounds when s64 crosses sign boundary Paul Chaignon
2025-07-24 13:43 ` [PATCH bpf-next v2 2/4] selftests/bpf: Update reg_bound range refinement logic Paul Chaignon
2025-07-24 13:43 ` [PATCH bpf-next v2 3/4] selftests/bpf: Test cross-sign 64bits range refinement Paul Chaignon
2025-07-24 19:15 ` Eduard Zingerman
2025-07-24 22:01 ` Paul Chaignon
2025-07-24 23:52 ` Eduard Zingerman [this message]
2025-07-25 7:15 ` Eduard Zingerman
2025-07-26 10:07 ` Paul Chaignon
2025-07-27 22:01 ` Eduard Zingerman
2025-07-24 13:44 ` [PATCH bpf-next v2 4/4] selftests/bpf: Test invariants on JSLT crossing sign Paul Chaignon
2025-07-24 19:24 ` 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=6d75ad3a05ebf56ab2f68e677264e8142c372fbc.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=paul.chaignon@gmail.com \
--cc=shung-hsi.yu@suse.com \
--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;
as well as URLs for NNTP newsgroup(s).