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 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?)

Do you know if there's anything I could have done differently to have
the selftests picked up? Or maybe something we could change in AUTOSEL?

> 
> > Ah, I didn't know that. Definitely makes sense for bisecting.
> > I probably broke it at least once :(
> > 
> > [...]
> >