Re: [PATCH bpf v2 1/2] bpf: refine u32/s32 bounds when ranges cross min/max boundary

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

On Thu, Mar 19, 2026 at 03:03:07PM +0800, Shung-Hsi Yu wrote:
> On Tue, Mar 17, 2026 at 04:37:59PM +0100, Paul Chaignon wrote:
> > On Thu, Mar 12, 2026 at 02:45:47PM +0800, Shung-Hsi Yu wrote:
> > > On Fri, Mar 06, 2026 at 01:24:28AM +0100, Paul Chaignon wrote:
> > > > On Thu, Mar 05, 2026 at 04:18:42PM -0800, Eduard Zingerman wrote:
> > > > > On Fri, 2026-03-06 at 01:13 +0100, Paul Chaignon wrote:
> > > > > > On Thu, Mar 05, 2026 at 11:48:22AM -0800, Eduard Zingerman wrote:
> > > > 
> > > > [...]
> > > > 
> > > > > > > diff --git a/tools/testing/selftests/bpf/prog_tests/reg_bounds.c b/tools/testing/selftests/bpf/prog_tests/reg_bounds.c
> > > > > > > index 0322f817d07be5d003c17dd7cedfa3aa4197678e..04938d0d431b38e086b50fe28b99e4ad2682742e 100644
> > > > > > > --- a/tools/testing/selftests/bpf/prog_tests/reg_bounds.c
> > > > > > > +++ b/tools/testing/selftests/bpf/prog_tests/reg_bounds.c
> > > > > > > @@ -422,15 +422,69 @@ static bool is_valid_range(enum num_t t, struct range x)
> > > > 
> > > > [...]
> > > > 
> > > > > > Don't we usually put changes to this file in a separate commit, as for
> > > > > > test changes in general?
> > > > > 
> > > > > W/o this change the reg_bounds.c tests would fail.
> > > > > So far we tried to keep selftests passing for every commit,
> > > > > to help with any potential bisecting.
> > > 
> > > Similarly we have stable AUTOSEL tends to just pick up kernel/bpf/
> > > changes and not the selftests ones. e.g. both 76e954155b45 ("bpf:
> > > Introduce tnum_step to step through tnum's members") and efc11a667878
> > > ("bpf: Improve bounds when tnum has a single possible value") got picked
> > > for 6.18.17-rc1, but not 024cea2d647e "selftests/bpf: Avoid
> > > simplification of crafted bounds test".
> > 
> > I can send the selftest backports to the stable ml (unless you already
> > are on it?)
> 
> Requested in https://lore.kernel.org/all/xbjybmha7fdnnm5gn6p6jyppf4ud2r72rfabvej6egg545ozsu@a4qj43d3iu36/
> 
> We should be good now.

Thanks!

> 
> > Do you know if there's anything I could have done differently to have
> > the selftests picked up? ...
> 
> In this specific case above it would to be have the selftest change
> along with the kernel/bpf/verifier.c changes, all in one commit, like
> Eduard has reasoned.

I realized after sending that I was probably unclear. I meant anything I
could have done to have the *new* selftests picked up. From your answer
below, it sounds like no.

> 
> > Or maybe something we could change in AUTOSEL?
> 
> We can argue that the selftest was dependency that should go together,
> and that AUTOSEL should pick it up, but IIRC it is design to only pick
> up dependencies that comes before a commit. OTOH it would be nice to
> have it try picking up selftests in the same series whenever it picks a
> commit from there, but that sounds like a bigger ask.

Agree it would be nice but probably too much load for stable, even
assuming we have a fully-working stable BPF CI :(

> 
> ...