On Wed, Jul 13, 2022 at 11:45 PM Kumar Kartikeya Dwivedi
<memxor@xxxxxxxxx> wrote:
>
> On Thu, 14 Jul 2022 at 07:38, Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote:
> >
> > On Wed, Jul 13, 2022 at 4:15 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote:
> > >
> > > From: Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx>
> > >
> > > Test various cases of direct packet access (proper range propagation,
> > > comparison of packet pointers pointing into separate xdp_frames, and
> > > correct invalidation on packet drop (so that multiple packet pointers
> > > are usable safely in a dequeue program)).
> > >
> > > Signed-off-by: Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx>
> > > Signed-off-by: Toke Høiland-Jørgensen <toke@xxxxxxxxxx>
> > > ---
> >
> > Consider writing these tests as plain C BPF code and put them in
> > test_progs, is there anything you can't express in C and thus requires
> > test_verifier?
>
> Not really, but in general I like test_verifier because it stays
> immune to compiler shenanigans.
In general I dislike them because they are almost incomprehensible. So
unless there is a very particular sequence of low-level BPF assembly
instructions one needs to test, I'd always opt for test_progs as more
maintainable solution.
Things like making sure that verifier rejects invalid use of
particular objects or helpers doesn't seem to rely much on particular
assembly sequence and can and should be expressed with plain C.
> So going forward should test_verifier tests be avoided, and normal C
> tests (using SEC("?...")) be preferred for these cases?
In my opinion, yes, unless absolutely requiring low-level assembly to
express conditions which are otherwise hard to express reliably in C.
>
> >
> > > tools/testing/selftests/bpf/test_verifier.c | 29 +++-
> > > .../testing/selftests/bpf/verifier/dequeue.c | 160 ++++++++++++++++++
> > > 2 files changed, 180 insertions(+), 9 deletions(-)
> > > create mode 100644 tools/testing/selftests/bpf/verifier/dequeue.c
> > >
> >
> > [...]
