From: Eduard Zingerman <eddyz87@gmail.com>
To: Shung-Hsi Yu <shung-hsi.yu@suse.com>,
Ihor Solodrai <ihor.solodrai@linux.dev>
Cc: Paul Chaignon <paul.chaignon@gmail.com>,
bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Harishankar Vishwanathan <harishankar.vishwanathan@gmail.com>,
Kernel Team <kernel-team@meta.com>
Subject: Re: [PATCH bpf-next 1/1] bpf: Avoid one round of bounds deduction
Date: Thu, 05 Mar 2026 03:10:00 -0800 [thread overview]
Message-ID: <ff92fa059a5f5427fec24be6758afa033ee43af2.camel@gmail.com> (raw)
In-Reply-To: <umlxk5jo72ii4efzcethwcwtr7e4scq5iicb57huuhb3qtvcuc@xhl3c6acyzga>
On Thu, 2026-03-05 at 14:54 +0800, Shung-Hsi Yu wrote:
> On Wed, Mar 04, 2026 at 04:48:43PM -0800, Ihor Solodrai wrote:
> > On 3/3/26 11:27 AM, Paul Chaignon wrote:
> > > In commit 5dbb19b16ac49 ("bpf: Add third round of bounds deduction"), I
> > > added a new round of bounds deduction because two rounds were not enough
> > > to converge to a fixed point. This commit slightly refactor the bounds
> > > deduction logic such that two rounds are enough.
> > >
> > > In [1], Eduard noticed that after we improved the refinement logic, a
> > > third call to the bounds deduction (__reg_deduce_bounds) was needed to
> > > converge to a fixed point. More specifically, we needed this third call
> > > to improve the s64 range using the s32 range. We added the third call
> > > and postponed a more detailed analysis of the refinement logic.
> > >
> > > I've been looking into this more recently. To help, I wrote a high level
> > > sequence of all the refinements carried out in reg_bounds_sync. u64 ->
> > > s32 means we used the u64 ranges to improve the s32 ranges.
> > >
> > > /* __update_reg_bounds: */
> > > tnum -> {s32, u32, s64, u64}
> > > /* __reg_deduce_bounds: */
> > > for (3 times) {
> > > /* __reg32_deduce_bounds: */
> > > u64 -> {u32, s32}
> > > s64 -> {u32, s32}
> > > u64 -> s32
> > > s64 -> s32
> > > u32 -> s32
> > > s32 -> u32
> > > /* __reg64_deduce_bounds: */
> > > u64 -> s64
> > > s64 -> u64
> > > {u64, s64} -> {u64, s64}
> > > /* __reg_deduce_mixed_bounds: */
> > > u32 -> u64
> > > u32 -> s64
> > > {s32, s64} -> {s64, u64, tnum}
> > > }
> > > /* __reg_bound_offset: */
> > > {u64, u32} -> tnum
> > > /* __update_reg_bounds: */
> > > tnum -> {s32, u32, s64, u64}
> [...]
> > Hi Paul,
> >
> > (trying to do my part with the code reviews and learn in the process)
>
> +1, still
>
> > Side note: you might be interested to know that Eduard is working on
> > consolidating signed and unsigned domains [1].
>
> \o/
>
> When I last look into this[1] there's was the "Interval Analysis and
> Machine Arithmetic: Why Signedness Ignorance Is Bliss" paper[2] that
> looks rather promising. And lately there was also "Program Analysis
> Combining Generalized Bit-Level and Word-Level Abstractions"[3] (haven't
> read) that seems more specific to BPF verifier.
Thank you for the links, I've only seen [1].
I was about to send [a], feeling really smug about cbmc tests.
But then a much simpler solution [b] occurred when figuring out why
64-bit test can't be written.
I'll probably continue playing with cnums at leisure pace.
[a] https://github.com/eddyz87/bpf/tree/cnum-sync-bounds
[b] https://github.com/eddyz87/bpf/tree/32-bit-range-overflow
next prev parent reply other threads:[~2026-03-05 11:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-03 19:27 [PATCH bpf-next 1/1] bpf: Avoid one round of bounds deduction Paul Chaignon
2026-03-05 0:48 ` Ihor Solodrai
2026-03-05 6:54 ` Shung-Hsi Yu
2026-03-05 11:10 ` Eduard Zingerman [this message]
2026-03-05 13:15 ` Paul Chaignon
2026-03-09 5:52 ` Shung-Hsi Yu
2026-03-09 11:09 ` Paul Chaignon
2026-03-09 4:28 ` Shung-Hsi Yu
2026-03-05 12:50 ` Paul Chaignon
2026-03-06 4:14 ` Shung-Hsi Yu
2026-03-06 23:49 ` Paul Chaignon
2026-03-09 5:27 ` Shung-Hsi Yu
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=ff92fa059a5f5427fec24be6758afa033ee43af2.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=harishankar.vishwanathan@gmail.com \
--cc=ihor.solodrai@linux.dev \
--cc=kernel-team@meta.com \
--cc=paul.chaignon@gmail.com \
--cc=shung-hsi.yu@suse.com \
/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.