On Fri, Dec 13, 2019 at 1:23 PM Stanislav Fomichev <sdf@xxxxxxxxxxx> wrote: > > On 12/13, Alexei Starovoitov wrote: > > On Wed, Dec 11, 2019 at 9:53 AM Stanislav Fomichev <sdf@xxxxxxxxxx> wrote: > > > > > > wire_len should not be less than real len and is capped by GSO_MAX_SIZE. > > > gso_segs is capped by GSO_MAX_SEGS. > > > > > > Signed-off-by: Stanislav Fomichev <sdf@xxxxxxxxxx> > > > > This change breaks tests: > > ./test_progs -n 16 > > test_kfree_skb:PASS:prog_load sched cls 0 nsec > > test_kfree_skb:PASS:prog_load raw tp 0 nsec > > test_kfree_skb:PASS:find_prog 0 nsec > > test_kfree_skb:PASS:find_prog 0 nsec > > test_kfree_skb:PASS:find_prog 0 nsec > > test_kfree_skb:PASS:find global data 0 nsec > > test_kfree_skb:PASS:attach_raw_tp 0 nsec > > test_kfree_skb:PASS:attach fentry 0 nsec > > test_kfree_skb:PASS:attach fexit 0 nsec > > test_kfree_skb:PASS:find_perf_buf_map 0 nsec > > test_kfree_skb:PASS:perf_buf__new 0 nsec > > test_kfree_skb:FAIL:ipv6 err -1 errno 22 retval 0 duration 0 > > on_sample:PASS:check_size 0 nsec > > on_sample:PASS:check_meta_ifindex 0 nsec > > on_sample:PASS:check_cb8_0 0 nsec > > on_sample:PASS:check_cb32_0 0 nsec > > on_sample:PASS:check_eth 0 nsec > > on_sample:PASS:check_ip 0 nsec > > on_sample:PASS:check_tcp 0 nsec > > test_kfree_skb:PASS:perf_buffer__poll 0 nsec > > test_kfree_skb:PASS:get_result 0 nsec > > #16 kfree_skb:FAIL > > Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED > Ugh, it's probably because of '__skb->wire_len < skb->len' check. > Let me take a look. > > (sorry, I'm still not running/looking at full test_progs because BTF support > is WIP in our toolchain and some subtests fail because of that, > generating a bunch of noise). I thought all bpf-next developers are developing against that tree ? Are you saying you cannot install the latest clang/pahole on your development system? git pull llvm;ninja;ninja install; git pull pahole; cmake;make why is it not possible? Now your complains about skeleton make more sense, but it's an issue with your particular setup. Anyway I'm not sure that this test issue is actually an issue with your patch. It could be that this test is flaky in a weird way. Just with and without your kernel patch it's 100% reproducible for me and I need to keep the rest of the patches moving without introducing failures in my test setup. All that will get resolved when we have kernel CI.
