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.
