From: Paul Chaignon <paul.chaignon@gmail.com>
To: Eduard Zingerman <eddyz87@gmail.com>
Cc: Harishankar Vishwanathan <harishankar.vishwanathan@gmail.com>,
bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Srinivas Narayana <srinivas.narayana@rutgers.edu>,
Santosh Nagarakatte <santosh.nagarakatte@rutgers.edu>
Subject: Re: [PATCH bpf 2/4] bpf: Improve bounds when tnum has a single possible value
Date: Fri, 20 Feb 2026 01:13:53 +0100 [thread overview]
Message-ID: <aZenQb3H5g73Bhz9@mail.gmail.com> (raw)
In-Reply-To: <aZdcoaH9ERUNpln1@mail.gmail.com>
On Thu, Feb 19, 2026 at 07:55:33PM +0100, Paul Chaignon wrote:
> On Thu, Feb 19, 2026 at 10:32:19AM -0800, Eduard Zingerman wrote:
> > On Wed, 2026-02-18 at 01:06 -0500, Harishankar Vishwanathan wrote:
> > > On Tue, Feb 17, 2026 at 5:58 PM Eduard Zingerman <eddyz87@gmail.com> wrote:
> > > [...]
> > > > > 1. The u64 range and the tnum only overlap in umin.
> > > > > u64: ---[xxxxxx]-----
> > > > > tnum: --xx----------x-
> > > > I think this hunk should be rewritten as follows:
> > > >
> > > > tnum_next = tnum_step(reg->var_off, reg->umin_value);
> > > > tnum_max = reg->var_off.value | reg->var_off.mask;
> > > > tnum_min = reg->var_off.value;
> > > > if (tnum_next > reg->umax_value) {
> > > > /* The only overlap is umin */
> > > > ___mark_reg_known(reg, tnum_min);
> > > > } else if (tnum_min < reg->umin_value && tnum_next == tnum_max) {
> > > > /* The only overlap is tmax */
> > > > ___mark_reg_known(reg, tnum_next);
> > > > } else if (tnum_next <= reg->umax_value &&
> > > > tnum_step(reg->var_off, tnum_next) > reg->umax_value) {
> > > > ___mark_reg_known(reg, tnum_next);
Actually, that last condition is not enough. In the original patch we
also would check that umin is not part of the tnum. That's needed for
example if we have R3=(u64=[0; 1], var_off=unknown) (a case possible
because __update_reg_bounds is the first refinement step in
reg_bounds_sync). With those values, we would match the third condition
and set R3=1.
Checking that tmin < reg->umin_value in the third condition would also
not work. For example R3=(u64=[0xffff; 0x10000], var_off=(0; 0x1ffff))
would be incorrectly simplified to R3=0x10000 because tmin=0,
umin=0xffff.
What we really want is to check that umin is not already part of the
tnum, as in the original patch. I think we can however improve
readability as you did. Here's what I have in mind:
tnum_next = tnum_step(reg->var_off, reg->umin_value);
umin_in_tnum = (reg->umin_value & ~reg->var_off.mask) == reg->var_off.value;
tmax = reg->var_off.value | reg->var_off.mask;
if (tnum_next > reg->umax_value) {
/* The u64 range and the tnum only overlap in umin.
* u64: ---[xxxxxx]-----
* tnum: --xx----------x-
*/
___mark_reg_known(reg, reg->umin_value);
} else if (!umin_in_tnum && tnum_next == tmax) {
/* The u64 range and the tnum only overlap in the maximum value
* represented by the tnum, called tmax.
* u64: ---[xxxxxx]-----
* tnum: xx-----x--------
*/
___mark_reg_known(reg, tmax);
} else if (!umin_in_tnum && tnum_next <= reg->umax_value &&
tnum_step(reg->var_off, tnum_next) > reg->umax_value) {
/* The u64 range and the tnum only overlap once in between umin
* (excluded) and umax.
* u64: ---[xxxxxx]-----
* tnum: xx----x-------x-
*/
___mark_reg_known(reg, tnum_next);
}
Wdyt?
[...]
next prev parent reply other threads:[~2026-02-20 0:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-17 8:53 [PATCH bpf 0/4] Fix invariant violation for single-value tnums Paul Chaignon
2026-02-17 8:59 ` [PATCH bpf 1/4] bpf: Introduce tnum_step to step through tnum's members Paul Chaignon
2026-02-17 9:44 ` bot+bpf-ci
2026-02-18 2:36 ` Harishankar Vishwanathan
2026-02-18 2:51 ` Alexei Starovoitov
2026-02-18 6:17 ` Harishankar Vishwanathan
2026-02-17 9:01 ` [PATCH bpf 2/4] bpf: Improve bounds when tnum has a single possible value Paul Chaignon
2026-02-17 18:58 ` Alexei Starovoitov
2026-02-17 22:57 ` Eduard Zingerman
2026-02-18 6:06 ` Harishankar Vishwanathan
2026-02-19 18:32 ` Eduard Zingerman
2026-02-19 18:55 ` Paul Chaignon
2026-02-20 0:13 ` Paul Chaignon [this message]
2026-02-20 1:29 ` Eduard Zingerman
2026-02-20 6:34 ` Harishankar Vishwanathan
2026-02-20 14:02 ` Paul Chaignon
2026-02-17 9:04 ` [PATCH bpf 3/4] selftests/bpf: Test refinement of single-value tnum Paul Chaignon
2026-02-17 9:06 ` [PATCH bpf 4/4] selftests/bpf: Avoid simplification of crafted bounds test 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=aZenQb3H5g73Bhz9@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=eddyz87@gmail.com \
--cc=harishankar.vishwanathan@gmail.com \
--cc=santosh.nagarakatte@rutgers.edu \
--cc=srinivas.narayana@rutgers.edu \
/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.