bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

[...]

  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).