On Wed, Mar 2, 2022 at 1:46 PM Daniel Borkmann <daniel@xxxxxxxxxxxxx> wrote:
>
> On 3/2/22 10:23 PM, Alexei Starovoitov wrote:
> > On Tue, Mar 01, 2022 at 02:27:45PM -0800, Mykola Lysenko wrote:
> >> .prog_type = BPF_PROG_TYPE_SCHED_CLS,
> >> .matches = {
> >> - {6, "R3_w=inv(id=0,umax_value=255,var_off=(0x0; 0xff))"},
> >> - {7, "R4_w=inv(id=1,umax_value=255,var_off=(0x0; 0xff))"},
> >> - {8, "R4_w=inv(id=0,umax_value=255,var_off=(0x0; 0xff))"},
> >> - {9, "R4_w=inv(id=1,umax_value=255,var_off=(0x0; 0xff))"},
> >> - {10, "R4_w=inv(id=0,umax_value=510,var_off=(0x0; 0x1fe))"},
> >> - {11, "R4_w=inv(id=1,umax_value=255,var_off=(0x0; 0xff))"},
> >> - {12, "R4_w=inv(id=0,umax_value=1020,var_off=(0x0; 0x3fc))"},
> >> - {13, "R4_w=inv(id=1,umax_value=255,var_off=(0x0; 0xff))"},
> >> - {14, "R4_w=inv(id=0,umax_value=2040,var_off=(0x0; 0x7f8))"},
> >> - {15, "R4_w=inv(id=0,umax_value=4080,var_off=(0x0; 0xff0))"},
> >> + {6, "R3_w=scalar(umax=255,var_off=(0x0; 0xff))"},
> >> + {7, "R4_w=scalar(id=1,umax=255,var_off=(0x0; 0xff))"},
> >> + {8, "R4_w=scalar(umax=255,var_off=(0x0; 0xff))"},
> >> + {9, "R4_w=scalar(id=1,umax=255,var_off=(0x0; 0xff))"},
> >> + {10, "R4_w=scalar(umax=510,var_off=(0x0; 0x1fe))"},
> >> + {11, "R4_w=scalar(id=1,umax=255,var_off=(0x0; 0xff))"},
> >> + {12, "R4_w=scalar(umax=1020,var_off=(0x0; 0x3fc))"},
> >> + {13, "R4_w=scalar(id=1,umax=255,var_off=(0x0; 0xff))"},
> >> + {14, "R4_w=scalar(umax=2040,var_off=(0x0; 0x7f8))"},
> >> + {15, "R4_w=scalar(umax=4080,var_off=(0x0; 0xff0))"},
> >
> > Sorry for the later review.
> > Would "int" be more precise and less verbose than "scalar"?
>
> Could work as well, although in many places today we make use of the term "scalar",
> so developers might be more familiar with it (and more consistent towards the
> verifier type internals).
I was focusing more on users who will see these logs and
would have to interpret them.
I suspect the ratio is 1 developer to 1000 users.
The users have to fight the verifier quite a bit to make the program pass.
I was thinking about "i64" too. That's what llvm is using,
but it's less clear than "int", which should be obvious
for users since they write progs in C.
It's also shorter.
I can live with "scalar" though.
