On Fri, Dec 15, 2023 at 7:24 AM Andrii Nakryiko
<andrii.nakryiko@xxxxxxxxx> wrote:
>
> On Wed, Dec 13, 2023 at 10:28 PM Menglong Dong <menglong8.dong@xxxxxxxxx> wrote:
> >
> > The edge range checking for the registers is supported by the verifier
> > now, so we can activate the extended login in
> > tools/testing/selftests/bpf/prog_tests/reg_bounds.c/range_cond() to test
> > such logic.
> >
> > Besides, I added some cases to the "crafted_cases" array for this logic.
> > These cases are mainly used to test the edge of the src reg and dst reg.
> >
> > Signed-off-by: Menglong Dong <menglong8.dong@xxxxxxxxx>
> > ---
> > v2:
> > - add some cases to the "crafted_cases"
> > ---
> > .../selftests/bpf/prog_tests/reg_bounds.c | 25 ++++++++++++++-----
> > 1 file changed, 19 insertions(+), 6 deletions(-)
> >
> > diff --git a/tools/testing/selftests/bpf/prog_tests/reg_bounds.c b/tools/testing/selftests/bpf/prog_tests/reg_bounds.c
> > index 0c9abd279e18..53b8711cfd2d 100644
> > --- a/tools/testing/selftests/bpf/prog_tests/reg_bounds.c
> > +++ b/tools/testing/selftests/bpf/prog_tests/reg_bounds.c
> > @@ -590,12 +590,7 @@ static void range_cond(enum num_t t, struct range x, struct range y,
> > *newy = range(t, max_t(t, x.a, y.a), min_t(t, x.b, y.b));
> > break;
> > case OP_NE:
> > - /* generic case, can't derive more information */
> > - *newx = range(t, x.a, x.b);
> > - *newy = range(t, y.a, y.b);
> > - break;
> > -
> > - /* below extended logic is not supported by verifier just yet */
> > + /* below logic is supported by the verifier now */
> > if (x.a == x.b && x.a == y.a) {
> > /* X is a constant matching left side of Y */
> > *newx = range(t, x.a, x.b);
> > @@ -2101,6 +2096,24 @@ static struct subtest_case crafted_cases[] = {
> > {S32, S64, {(u32)(s32)S32_MIN, (u32)(s32)-255}, {(u32)(s32)-2, 0}},
> > {S32, S64, {0, 1}, {(u32)(s32)S32_MIN, (u32)(s32)S32_MIN}},
> > {S32, U32, {(u32)(s32)S32_MIN, (u32)(s32)S32_MIN}, {(u32)(s32)S32_MIN, (u32)(s32)S32_MIN}},
> > +
> > + /* edge overlap testings for BPF_NE */
> > + {U64, U64, {1, 1}, {1, 0x80000000}},
> > + {U64, S64, {1, 1}, {1, 0x80000000}},
> > + {U64, U32, {1, 1}, {1, 0x80000000}},
> > + {U64, S32, {1, 1}, {1, 0x80000000}},
> > + {U64, U64, {0x80000000, 0x80000000}, {1, 0x80000000}},
> > + {U64, S64, {0x80000000, 0x80000000}, {1, 0x80000000}},
> > + {U64, U32, {0x80000000, 0x80000000}, {1, 0x80000000}},
> > + {U64, S32, {0x80000000, 0x80000000}, {1, 0x80000000}},
> > + {U64, U64, {1, 0x80000000}, {1, 1}},
> > + {U64, S64, {1, 0x80000000}, {1, 1}},
> > + {U64, U32, {1, 0x80000000}, {1, 1}},
> > + {U64, S32, {1, 0x80000000}, {1, 1}},
> > + {U64, U64, {1, 0x80000000}, {0x80000000, 0x80000000}},
> > + {U64, S64, {1, 0x80000000}, {0x80000000, 0x80000000}},
> > + {U64, U32, {1, 0x80000000}, {0x80000000, 0x80000000}},
> > + {U64, S32, {1, 0x80000000}, {0x80000000, 0x80000000}},
>
> JNE and JEQ are sign-agnostic, so there is no need to use both U64 and
> S64 variants for comparison. As for the choice of values. Wouldn't it
> make sense to use really a boundary conditions:
>
> 0, 0xffffffffffffffff, and 0x80000000000000 for 64-bit and
> 0, 0xffffffff, and 0x80000000 for 32-bit? For this one use U32 as the init type?
>
Yeah, this makes sense.
> BTW, all these cases should be tested with auto-generated tests, so
> please make sure to run
>
> sudo SLOW_TESTS=1 ./test_progs -t reg_bounds_gen -j
>
> locally. It will take a bit of time, but should help to get confidence
> in that everything is working and nothing regressed.
>
I have already run the slow testing (it indeed takes some time)
and everything works well. I'll add the test results to the commit
log in the next version too.
Thanks!
Menglong Dong
> > };
> >
> > /* Go over crafted hard-coded cases. This is fast, so we do it as part of
> > --
> > 2.39.2
> >
