Re: [PATCH bpf-next v3 0/4] xdp: recycle Page Pool backed skbs built from XDP frames

[Alexei Starovoitov]

On Tue, Mar 14, 2023 at 11:52 AM Alexei Starovoitov
<alexei.starovoitov@xxxxxxxxx> wrote:
>
> On Tue, Mar 14, 2023 at 4:58 AM Alexander Lobakin
> <aleksander.lobakin@xxxxxxxxx> wrote:
> >
> >   All error logs:
> >   libbpf: prog 'trace_virtqueue_add_sgs': BPF program load failed: Bad
> > address
> >   libbpf: prog 'trace_virtqueue_add_sgs': -- BEGIN PROG LOAD LOG --
> >   The sequence of 8193 jumps is too complex.
> >   verification time 77808 usec
> >   stack depth 64
> >   processed 156616 insns (limit 1000000) max_states_per_insn 8
> > total_states 1754 peak_states 1712 mark_read 12
> >   -- END PROG LOAD LOG --
> >   libbpf: prog 'trace_virtqueue_add_sgs': failed to load: -14
> >   libbpf: failed to load object 'loop6.bpf.o'
> >   scale_test:FAIL:expect_success unexpected error: -14 (errno 14)
> >   #257     verif_scale_loop6:FAIL
> >   Summary: 288/1766 PASSED, 21 SKIPPED, 1 FAILED
> >
> > So, xdp_do_redirect, which was previously failing, now works fine. OTOH,
> > "verif_scale_loop6" now fails, but from what I understand from the log,
> > it has nothing with the series ("8193 jumps is too complex" -- I don't
> > even touch program-related stuff). I don't know what's the reason of it
> > failing, can it be some CI issues or maybe some recent commits?
>
> Yeah. It's an issue with the latest clang.
> We don't have a workaround for this yet.
> It's not a blocker for your patchset.
> We didn't have time to look at it closely.

I applied the workaround for this test.
It's all green now except s390 where it fails with

test_xdp_do_redirect:PASS:prog_run 0 nsec
test_xdp_do_redirect:PASS:pkt_count_xdp 0 nsec
test_xdp_do_redirect:PASS:pkt_count_zero 0 nsec
test_xdp_do_redirect:FAIL:pkt_count_tc unexpected pkt_count_tc: actual
220 != expected 9998
test_max_pkt_size:PASS:prog_run_max_size 0 nsec
test_max_pkt_size:PASS:prog_run_too_big 0 nsec
close_netns:PASS:setns 0 nsec
#289 xdp_do_redirect:FAIL
Summary: 270/1674 PASSED, 30 SKIPPED, 1 FAILED

Alex,
could you please take a look at why it's happening?

I suspect it's an endianness issue in:
        if (*metadata != 0x42)
                return XDP_ABORTED;
but your patch didn't change that,
so I'm not sure why it worked before.