Re: [PATCH bpf-next] selftests/bpf: Fix test for refinement of single-value tnum

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

On Mon, May 18, 2026 at 05:09:21PM +0000, bot+bpf-ci@kernel.org wrote:
> > diff --git a/tools/testing/selftests/bpf/progs/verifier_bounds.c b/tools/testing/selftests/bpf/progs/verifier_bounds.c
> > index a3e4c0945137..bc038ac2df98 100644
> > --- a/tools/testing/selftests/bpf/progs/verifier_bounds.c
> > +++ b/tools/testing/selftests/bpf/progs/verifier_bounds.c
> > @@ -1892,25 +1892,25 @@ __naked void bounds_refinement_tnum_umax(void *ctx)
> >  /* This test covers the bounds deduction when the u64 range and the tnum
> >   * overlap only at umin. After instruction 3, the ranges look as follows:
> >   *
> > - * 0    umin=0xe00     umax=0xeff                              U64_MAX
> > + * 0    umin=0xe1      umax=0xf0                               U64_MAX
>                               ^^^^^
> 
> The comment says umax=0xf0 but looking at the code change below:
> 
> >   * |    [xxxxxxxxxxxxxx]                                       |
> >   * |----------------------------|------------------------------|
> >   * |    x               x                                      | tnum values
> >   *
> > - * The verifier can therefore deduce that the R0=0xe0=224.
> > + * The verifier can therefore deduce that the R0=0xe1=225.
> >   */
> >  SEC("socket")
> >  __description("bounds refinement with single-value tnum on umin")
> > -__msg("3: (15) if r0 == 0xf0 {{.*}} R0=224")
> > +__msg("3: (15) if r0 == 0xf1 {{.*}} R0=225")
> >  __success __log_level(2)
> >  __naked void bounds_refinement_tnum_umin(void *ctx)
> >  {
> >  	asm volatile("			\
> >  	call %[bpf_get_prandom_u32];	\
> > -	r0 |= 0xe0;			\
> > -	r0 &= 0xf0;			\
> > -	if r0 == 0xf0 goto +2;		\
> > -	if r0 == 0xe0 goto +1;		\
> > +	r0 |= 0xe1;			\
> > +	r0 &= 0xf1;			\
>                    ^^^^
> 
> After r0 |= 0xe1, the register has umin=0xe1. Then after r0 &= 0xf1,
> the mask 0xf1 allows bits 11110001, which permits both 0xe1 and 0xf1.
> This creates a u64 range of [0xe1, 0xf1], not [0xe1, 0xf0] as stated
> in the comment.

That's correct. But after instruction 3, on the fallthrough path, we can
also deduce that R0 != 0xf1 and our existing refinement logic can thus
tighten the u64 range to [0xe1; 0xf0]. The comment is therefore correct.

> 
> Should the comment be updated to umax=0xf1 to match the implementation?
> 
> 
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
> 
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/26047251229