| Message ID | 20190522092323.17435-1-bjorn.topel@gmail.com |
|---|---|
| State | Accepted |
| Delegated to: | BPF Maintainers |
| Headers | show |
| Series | [bpf] selftests: bpf: add zero extend checks for ALU32 and/or/xor | expand |
On Wed, May 22, 2019 at 2:25 AM Björn Töpel <bjorn.topel@gmail.com> wrote: > > Add three tests to test_verifier/basic_instr that make sure that the > high 32-bits of the destination register is cleared after an ALU32 > and/or/xor. > > Signed-off-by: Björn Töpel <bjorn.topel@gmail.com> I think the patch intends for bpf-next, right? The patch itself looks good to me. Acked-by: Yonghong Song <yhs@fb.com> > --- > .../selftests/bpf/verifier/basic_instr.c | 39 +++++++++++++++++++ > 1 file changed, 39 insertions(+) > > diff --git a/tools/testing/selftests/bpf/verifier/basic_instr.c b/tools/testing/selftests/bpf/verifier/basic_instr.c > index ed91a7b9a456..4d844089938e 100644 > --- a/tools/testing/selftests/bpf/verifier/basic_instr.c > +++ b/tools/testing/selftests/bpf/verifier/basic_instr.c > @@ -132,3 +132,42 @@ > .prog_type = BPF_PROG_TYPE_SCHED_CLS, > .result = ACCEPT, > }, > +{ > + "and32 reg zero extend check", > + .insns = { > + BPF_MOV64_IMM(BPF_REG_0, -1), > + BPF_MOV64_IMM(BPF_REG_2, -2), > + BPF_ALU32_REG(BPF_AND, BPF_REG_0, BPF_REG_2), > + BPF_ALU64_IMM(BPF_RSH, BPF_REG_0, 32), > + BPF_EXIT_INSN(), > + }, > + .prog_type = BPF_PROG_TYPE_SCHED_CLS, > + .result = ACCEPT, > + .retval = 0, > +}, > +{ > + "or32 reg zero extend check", > + .insns = { > + BPF_MOV64_IMM(BPF_REG_0, -1), > + BPF_MOV64_IMM(BPF_REG_2, -2), > + BPF_ALU32_REG(BPF_OR, BPF_REG_0, BPF_REG_2), > + BPF_ALU64_IMM(BPF_RSH, BPF_REG_0, 32), > + BPF_EXIT_INSN(), > + }, > + .prog_type = BPF_PROG_TYPE_SCHED_CLS, > + .result = ACCEPT, > + .retval = 0, > +}, > +{ > + "xor32 reg zero extend check", > + .insns = { > + BPF_MOV64_IMM(BPF_REG_0, -1), > + BPF_MOV64_IMM(BPF_REG_2, 0), > + BPF_ALU32_REG(BPF_XOR, BPF_REG_0, BPF_REG_2), > + BPF_ALU64_IMM(BPF_RSH, BPF_REG_0, 32), > + BPF_EXIT_INSN(), > + }, > + .prog_type = BPF_PROG_TYPE_SCHED_CLS, > + .result = ACCEPT, > + .retval = 0, > +}, > -- > 2.20.1 >
On Wed, 22 May 2019 at 20:13, Y Song <ys114321@gmail.com> wrote: > > On Wed, May 22, 2019 at 2:25 AM Björn Töpel <bjorn.topel@gmail.com> wrote: > > > > Add three tests to test_verifier/basic_instr that make sure that the > > high 32-bits of the destination register is cleared after an ALU32 > > and/or/xor. > > > > Signed-off-by: Björn Töpel <bjorn.topel@gmail.com> > > I think the patch intends for bpf-next, right? The patch itself looks > good to me. > Acked-by: Yonghong Song <yhs@fb.com> > Thank you. Actually, it was intended for the bpf tree, as a test follow up for this [1] fix. Cheers, Björn [1] https://lore.kernel.org/bpf/CAJ+HfNifkxKz8df7gLBuqWA6+t6awrrRK6oW6m1nAYETJD+Vfg@mail.gmail.com/ > > --- > > .../selftests/bpf/verifier/basic_instr.c | 39 +++++++++++++++++++ > > 1 file changed, 39 insertions(+) > > > > diff --git a/tools/testing/selftests/bpf/verifier/basic_instr.c b/tools/testing/selftests/bpf/verifier/basic_instr.c > > index ed91a7b9a456..4d844089938e 100644 > > --- a/tools/testing/selftests/bpf/verifier/basic_instr.c > > +++ b/tools/testing/selftests/bpf/verifier/basic_instr.c > > @@ -132,3 +132,42 @@ > > .prog_type = BPF_PROG_TYPE_SCHED_CLS, > > .result = ACCEPT, > > }, > > +{ > > + "and32 reg zero extend check", > > + .insns = { > > + BPF_MOV64_IMM(BPF_REG_0, -1), > > + BPF_MOV64_IMM(BPF_REG_2, -2), > > + BPF_ALU32_REG(BPF_AND, BPF_REG_0, BPF_REG_2), > > + BPF_ALU64_IMM(BPF_RSH, BPF_REG_0, 32), > > + BPF_EXIT_INSN(), > > + }, > > + .prog_type = BPF_PROG_TYPE_SCHED_CLS, > > + .result = ACCEPT, > > + .retval = 0, > > +}, > > +{ > > + "or32 reg zero extend check", > > + .insns = { > > + BPF_MOV64_IMM(BPF_REG_0, -1), > > + BPF_MOV64_IMM(BPF_REG_2, -2), > > + BPF_ALU32_REG(BPF_OR, BPF_REG_0, BPF_REG_2), > > + BPF_ALU64_IMM(BPF_RSH, BPF_REG_0, 32), > > + BPF_EXIT_INSN(), > > + }, > > + .prog_type = BPF_PROG_TYPE_SCHED_CLS, > > + .result = ACCEPT, > > + .retval = 0, > > +}, > > +{ > > + "xor32 reg zero extend check", > > + .insns = { > > + BPF_MOV64_IMM(BPF_REG_0, -1), > > + BPF_MOV64_IMM(BPF_REG_2, 0), > > + BPF_ALU32_REG(BPF_XOR, BPF_REG_0, BPF_REG_2), > > + BPF_ALU64_IMM(BPF_RSH, BPF_REG_0, 32), > > + BPF_EXIT_INSN(), > > + }, > > + .prog_type = BPF_PROG_TYPE_SCHED_CLS, > > + .result = ACCEPT, > > + .retval = 0, > > +}, > > -- > > 2.20.1 > >
On Wed, May 22, 2019 at 1:46 PM Björn Töpel <bjorn.topel@gmail.com> wrote: > > On Wed, 22 May 2019 at 20:13, Y Song <ys114321@gmail.com> wrote: > > > > On Wed, May 22, 2019 at 2:25 AM Björn Töpel <bjorn.topel@gmail.com> wrote: > > > > > > Add three tests to test_verifier/basic_instr that make sure that the > > > high 32-bits of the destination register is cleared after an ALU32 > > > and/or/xor. > > > > > > Signed-off-by: Björn Töpel <bjorn.topel@gmail.com> > > > > I think the patch intends for bpf-next, right? The patch itself looks > > good to me. > > Acked-by: Yonghong Song <yhs@fb.com> > > > > Thank you. Actually, it was intended for the bpf tree, as a test > follow up for this [1] fix. Then maybe you want to add a Fixes tag and resubmit? > > > Cheers, > Björn > > [1] https://lore.kernel.org/bpf/CAJ+HfNifkxKz8df7gLBuqWA6+t6awrrRK6oW6m1nAYETJD+Vfg@mail.gmail.com/ > > > > --- > > > .../selftests/bpf/verifier/basic_instr.c | 39 +++++++++++++++++++ > > > 1 file changed, 39 insertions(+) > > > > > > diff --git a/tools/testing/selftests/bpf/verifier/basic_instr.c b/tools/testing/selftests/bpf/verifier/basic_instr.c > > > index ed91a7b9a456..4d844089938e 100644 > > > --- a/tools/testing/selftests/bpf/verifier/basic_instr.c > > > +++ b/tools/testing/selftests/bpf/verifier/basic_instr.c > > > @@ -132,3 +132,42 @@ > > > .prog_type = BPF_PROG_TYPE_SCHED_CLS, > > > .result = ACCEPT, > > > }, > > > +{ > > > + "and32 reg zero extend check", > > > + .insns = { > > > + BPF_MOV64_IMM(BPF_REG_0, -1), > > > + BPF_MOV64_IMM(BPF_REG_2, -2), > > > + BPF_ALU32_REG(BPF_AND, BPF_REG_0, BPF_REG_2), > > > + BPF_ALU64_IMM(BPF_RSH, BPF_REG_0, 32), > > > + BPF_EXIT_INSN(), > > > + }, > > > + .prog_type = BPF_PROG_TYPE_SCHED_CLS, > > > + .result = ACCEPT, > > > + .retval = 0, > > > +}, > > > +{ > > > + "or32 reg zero extend check", > > > + .insns = { > > > + BPF_MOV64_IMM(BPF_REG_0, -1), > > > + BPF_MOV64_IMM(BPF_REG_2, -2), > > > + BPF_ALU32_REG(BPF_OR, BPF_REG_0, BPF_REG_2), > > > + BPF_ALU64_IMM(BPF_RSH, BPF_REG_0, 32), > > > + BPF_EXIT_INSN(), > > > + }, > > > + .prog_type = BPF_PROG_TYPE_SCHED_CLS, > > > + .result = ACCEPT, > > > + .retval = 0, > > > +}, > > > +{ > > > + "xor32 reg zero extend check", > > > + .insns = { > > > + BPF_MOV64_IMM(BPF_REG_0, -1), > > > + BPF_MOV64_IMM(BPF_REG_2, 0), > > > + BPF_ALU32_REG(BPF_XOR, BPF_REG_0, BPF_REG_2), > > > + BPF_ALU64_IMM(BPF_RSH, BPF_REG_0, 32), > > > + BPF_EXIT_INSN(), > > > + }, > > > + .prog_type = BPF_PROG_TYPE_SCHED_CLS, > > > + .result = ACCEPT, > > > + .retval = 0, > > > +}, > > > -- > > > 2.20.1 > > >
On Thu, 23 May 2019 at 08:39, Y Song <ys114321@gmail.com> wrote: > > On Wed, May 22, 2019 at 1:46 PM Björn Töpel <bjorn.topel@gmail.com> wrote: > > > > On Wed, 22 May 2019 at 20:13, Y Song <ys114321@gmail.com> wrote: > > > > > > On Wed, May 22, 2019 at 2:25 AM Björn Töpel <bjorn.topel@gmail.com> wrote: > > > > > > > > Add three tests to test_verifier/basic_instr that make sure that the > > > > high 32-bits of the destination register is cleared after an ALU32 > > > > and/or/xor. > > > > > > > > Signed-off-by: Björn Töpel <bjorn.topel@gmail.com> > > > > > > I think the patch intends for bpf-next, right? The patch itself looks > > > good to me. > > > Acked-by: Yonghong Song <yhs@fb.com> > > > > > > > Thank you. Actually, it was intended for the bpf tree, as a test > > follow up for this [1] fix. > Then maybe you want to add a Fixes tag and resubmit? Hmm, I thought that adding tests were OK for non-next. Should the Fixes: tag for the test reflex the corresponding fixed code (in this case the RV JIT)? > > > > > > Cheers, > > Björn > > > > [1] https://lore.kernel.org/bpf/CAJ+HfNifkxKz8df7gLBuqWA6+t6awrrRK6oW6m1nAYETJD+Vfg@mail.gmail.com/ > > > > > > --- > > > > .../selftests/bpf/verifier/basic_instr.c | 39 +++++++++++++++++++ > > > > 1 file changed, 39 insertions(+) > > > > > > > > diff --git a/tools/testing/selftests/bpf/verifier/basic_instr.c b/tools/testing/selftests/bpf/verifier/basic_instr.c > > > > index ed91a7b9a456..4d844089938e 100644 > > > > --- a/tools/testing/selftests/bpf/verifier/basic_instr.c > > > > +++ b/tools/testing/selftests/bpf/verifier/basic_instr.c > > > > @@ -132,3 +132,42 @@ > > > > .prog_type = BPF_PROG_TYPE_SCHED_CLS, > > > > .result = ACCEPT, > > > > }, > > > > +{ > > > > + "and32 reg zero extend check", > > > > + .insns = { > > > > + BPF_MOV64_IMM(BPF_REG_0, -1), > > > > + BPF_MOV64_IMM(BPF_REG_2, -2), > > > > + BPF_ALU32_REG(BPF_AND, BPF_REG_0, BPF_REG_2), > > > > + BPF_ALU64_IMM(BPF_RSH, BPF_REG_0, 32), > > > > + BPF_EXIT_INSN(), > > > > + }, > > > > + .prog_type = BPF_PROG_TYPE_SCHED_CLS, > > > > + .result = ACCEPT, > > > > + .retval = 0, > > > > +}, > > > > +{ > > > > + "or32 reg zero extend check", > > > > + .insns = { > > > > + BPF_MOV64_IMM(BPF_REG_0, -1), > > > > + BPF_MOV64_IMM(BPF_REG_2, -2), > > > > + BPF_ALU32_REG(BPF_OR, BPF_REG_0, BPF_REG_2), > > > > + BPF_ALU64_IMM(BPF_RSH, BPF_REG_0, 32), > > > > + BPF_EXIT_INSN(), > > > > + }, > > > > + .prog_type = BPF_PROG_TYPE_SCHED_CLS, > > > > + .result = ACCEPT, > > > > + .retval = 0, > > > > +}, > > > > +{ > > > > + "xor32 reg zero extend check", > > > > + .insns = { > > > > + BPF_MOV64_IMM(BPF_REG_0, -1), > > > > + BPF_MOV64_IMM(BPF_REG_2, 0), > > > > + BPF_ALU32_REG(BPF_XOR, BPF_REG_0, BPF_REG_2), > > > > + BPF_ALU64_IMM(BPF_RSH, BPF_REG_0, 32), > > > > + BPF_EXIT_INSN(), > > > > + }, > > > > + .prog_type = BPF_PROG_TYPE_SCHED_CLS, > > > > + .result = ACCEPT, > > > > + .retval = 0, > > > > +}, > > > > -- > > > > 2.20.1 > > > >
On 05/23/2019 08:38 AM, Y Song wrote: > On Wed, May 22, 2019 at 1:46 PM Björn Töpel <bjorn.topel@gmail.com> wrote: >> On Wed, 22 May 2019 at 20:13, Y Song <ys114321@gmail.com> wrote: >>> On Wed, May 22, 2019 at 2:25 AM Björn Töpel <bjorn.topel@gmail.com> wrote: >>>> >>>> Add three tests to test_verifier/basic_instr that make sure that the >>>> high 32-bits of the destination register is cleared after an ALU32 >>>> and/or/xor. >>>> >>>> Signed-off-by: Björn Töpel <bjorn.topel@gmail.com> >>> >>> I think the patch intends for bpf-next, right? The patch itself looks >>> good to me. >>> Acked-by: Yonghong Song <yhs@fb.com> >> >> Thank you. Actually, it was intended for the bpf tree, as a test >> follow up for this [1] fix. > Then maybe you want to add a Fixes tag and resubmit? Why would the test case need a fixes tag? It's common practice that we have BPF fixes that we queue to bpf tree along with kselftest test cases related to them. Therefore, applied as well, thanks for following up! Björn, in my email from the fix, I mentioned we should have test snippets ideally for all of the alu32 insns to not miss something falling through the cracks when JITs get added or changed. If you have some cycles to add the remaining missing ones, that would be much appreciated. Thanks, Daniel
> On 23 May 2019, at 15:02, Daniel Borkmann <daniel@iogearbox.net> wrote: > > On 05/23/2019 08:38 AM, Y Song wrote: >> On Wed, May 22, 2019 at 1:46 PM Björn Töpel <bjorn.topel@gmail.com> wrote: >>> On Wed, 22 May 2019 at 20:13, Y Song <ys114321@gmail.com> wrote: >>>> On Wed, May 22, 2019 at 2:25 AM Björn Töpel <bjorn.topel@gmail.com> wrote: >>>>> >>>>> Add three tests to test_verifier/basic_instr that make sure that the >>>>> high 32-bits of the destination register is cleared after an ALU32 >>>>> and/or/xor. >>>>> >>>>> Signed-off-by: Björn Töpel <bjorn.topel@gmail.com> >>>> >>>> I think the patch intends for bpf-next, right? The patch itself looks >>>> good to me. >>>> Acked-by: Yonghong Song <yhs@fb.com> >>> >>> Thank you. Actually, it was intended for the bpf tree, as a test >>> follow up for this [1] fix. >> Then maybe you want to add a Fixes tag and resubmit? > > Why would the test case need a fixes tag? It's common practice that we have > BPF fixes that we queue to bpf tree along with kselftest test cases related > to them. Therefore, applied as well, thanks for following up! > > Björn, in my email from the fix, I mentioned we should have test snippets > ideally for all of the alu32 insns to not miss something falling through the > cracks when JITs get added or changed. If you have some cycles to add the > remaining missing ones, that would be much appreciated. Björn, If you don’t have time, I can take this alu32 test case follow up as well. Regards, Jiong > > Thanks, > Daniel
On Thu, 23 May 2019 at 16:31, Jiong Wang <jiong.wang@netronome.com> wrote: > > > > On 23 May 2019, at 15:02, Daniel Borkmann <daniel@iogearbox.net> wrote: > > > > On 05/23/2019 08:38 AM, Y Song wrote: > >> On Wed, May 22, 2019 at 1:46 PM Björn Töpel <bjorn.topel@gmail.com> wrote: > >>> On Wed, 22 May 2019 at 20:13, Y Song <ys114321@gmail.com> wrote: > >>>> On Wed, May 22, 2019 at 2:25 AM Björn Töpel <bjorn.topel@gmail.com> wrote: > >>>>> > >>>>> Add three tests to test_verifier/basic_instr that make sure that the > >>>>> high 32-bits of the destination register is cleared after an ALU32 > >>>>> and/or/xor. > >>>>> > >>>>> Signed-off-by: Björn Töpel <bjorn.topel@gmail.com> > >>>> > >>>> I think the patch intends for bpf-next, right? The patch itself looks > >>>> good to me. > >>>> Acked-by: Yonghong Song <yhs@fb.com> > >>> > >>> Thank you. Actually, it was intended for the bpf tree, as a test > >>> follow up for this [1] fix. > >> Then maybe you want to add a Fixes tag and resubmit? > > > > Why would the test case need a fixes tag? It's common practice that we have > > BPF fixes that we queue to bpf tree along with kselftest test cases related > > to them. Therefore, applied as well, thanks for following up! > > > > Björn, in my email from the fix, I mentioned we should have test snippets > > ideally for all of the alu32 insns to not miss something falling through the > > cracks when JITs get added or changed. If you have some cycles to add the > > remaining missing ones, that would be much appreciated. > > Björn, > > If you don’t have time, I can take this alu32 test case follow up as well. > Jiong, that would be great. Thank you. I'd guess it would take much longer for me to do it (gmail.com time vs intel.com time ;-)). Björn > Regards, > Jiong > > > > > Thanks, > > Daniel >
diff --git a/tools/testing/selftests/bpf/verifier/basic_instr.c b/tools/testing/selftests/bpf/verifier/basic_instr.c index ed91a7b9a456..4d844089938e 100644 --- a/tools/testing/selftests/bpf/verifier/basic_instr.c +++ b/tools/testing/selftests/bpf/verifier/basic_instr.c @@ -132,3 +132,42 @@ .prog_type = BPF_PROG_TYPE_SCHED_CLS, .result = ACCEPT, }, +{ + "and32 reg zero extend check", + .insns = { + BPF_MOV64_IMM(BPF_REG_0, -1), + BPF_MOV64_IMM(BPF_REG_2, -2), + BPF_ALU32_REG(BPF_AND, BPF_REG_0, BPF_REG_2), + BPF_ALU64_IMM(BPF_RSH, BPF_REG_0, 32), + BPF_EXIT_INSN(), + }, + .prog_type = BPF_PROG_TYPE_SCHED_CLS, + .result = ACCEPT, + .retval = 0, +}, +{ + "or32 reg zero extend check", + .insns = { + BPF_MOV64_IMM(BPF_REG_0, -1), + BPF_MOV64_IMM(BPF_REG_2, -2), + BPF_ALU32_REG(BPF_OR, BPF_REG_0, BPF_REG_2), + BPF_ALU64_IMM(BPF_RSH, BPF_REG_0, 32), + BPF_EXIT_INSN(), + }, + .prog_type = BPF_PROG_TYPE_SCHED_CLS, + .result = ACCEPT, + .retval = 0, +}, +{ + "xor32 reg zero extend check", + .insns = { + BPF_MOV64_IMM(BPF_REG_0, -1), + BPF_MOV64_IMM(BPF_REG_2, 0), + BPF_ALU32_REG(BPF_XOR, BPF_REG_0, BPF_REG_2), + BPF_ALU64_IMM(BPF_RSH, BPF_REG_0, 32), + BPF_EXIT_INSN(), + }, + .prog_type = BPF_PROG_TYPE_SCHED_CLS, + .result = ACCEPT, + .retval = 0, +},
Add three tests to test_verifier/basic_instr that make sure that the high 32-bits of the destination register is cleared after an ALU32 and/or/xor. Signed-off-by: Björn Töpel <bjorn.topel@gmail.com> --- .../selftests/bpf/verifier/basic_instr.c | 39 +++++++++++++++++++ 1 file changed, 39 insertions(+)