Re: [PATCH bpf-next 1/1] bpf: Avoid one round of bounds deduction

[Paul Chaignon <paul.chaignon@gmail.com>]

On Mon, Mar 09, 2026 at 01:52:47PM +0800, Shung-Hsi Yu wrote:
> Cc Andrea and Emil from the other thread:
> 
>   https://lore.kernel.org/all/20260220190736.230329-1-arighi@nvidia.com/t/#u
> 
> On Thu, Mar 05, 2026 at 02:15:10PM +0100, Paul Chaignon wrote:
> > On Thu, Mar 05, 2026 at 03:10:00AM -0800, Eduard Zingerman wrote:
> > > 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:
> [...]
> > > 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
> > 
> > IIUC, your current patch doesn't maintain a cnum domain alongside the
> > existing abstract domain, but instead builds it only when needed, in
> > is_scalar_branch_taken. Would your long-term goal still be to replace
> > the existing four ranges with two cnum domains?
> 
> Borrowing upon the above, would like to about ask about the work on
> "avoiding inconsistent state with is_scalar_branch_taken vs
> reg_set_min_max difference". Is the current plan to address that once we
> have the cnum domains?

IMO, the two are fairly orthogonal. If cnum is merged first, then it may
help reduce invariant violations a bit (?). If it's merged in second, it
will probably improve is_branch_taken's accuracy a bit.

We're preparing a patchset with Hari (cc'ed) to use regs_refine_cond_op
for is_branch_taken. It should fix the invariant violations once and
for all—they're a pretty big syzbot sink at the moment for BPF :(
I'm currently collecting test cases from new syzbot reproducers and will
send it afterwards.