All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanislav Fomichev <sdf@fomichev.me>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Stanislav Fomichev <sdf@google.com>,
	Network Development <netdev@vger.kernel.org>,
	bpf <bpf@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>
Subject: Re: [PATCH bpf-next 1/2] bpf: expose __sk_buff wire_len/gso_segs to BPF_PROG_TEST_RUN
Date: Fri, 13 Dec 2019 14:06:00 -0800	[thread overview]
Message-ID: <20191213220600.GQ3105713@mini-arch> (raw)
In-Reply-To: <CAADnVQKB+JafsQT4qjgECc1WzhoRvisO86NfS3D5-v-OYW5KgQ@mail.gmail.com>

On 12/13, Alexei Starovoitov wrote:
> On Fri, Dec 13, 2019 at 1:23 PM Stanislav Fomichev <sdf@fomichev.me> wrote:
> >
> > On 12/13, Alexei Starovoitov wrote:
> > > On Wed, Dec 11, 2019 at 9:53 AM Stanislav Fomichev <sdf@google.com> 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@google.com>
> > >
> > > 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 ?
I am developing against that tree, but I have a wrapper around
make that points it to the proper version of cc/tools that we
use for prod builds (for consistency).

> 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?
Yeah, I'll do that now, it just requires some manual movements :-)

> 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.
No, I'm pretty sure that's that wire_len check. I think I need to add
a special case to set it to skb->len if it's zero.
Will follow up with a v2!

      reply	other threads:[~2019-12-13 22:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-11 17:53 [PATCH bpf-next 1/2] bpf: expose __sk_buff wire_len/gso_segs to BPF_PROG_TEST_RUN Stanislav Fomichev
2019-12-11 17:53 ` [PATCH bpf-next 2/2] selftests/bpf: test wire_len/gso_segs in BPF_PROG_TEST_RUN Stanislav Fomichev
2019-12-12 18:44   ` Martin Lau
2019-12-12 18:44 ` [PATCH bpf-next 1/2] bpf: expose __sk_buff wire_len/gso_segs to BPF_PROG_TEST_RUN Martin Lau
2019-12-13 20:55 ` Alexei Starovoitov
2019-12-13 21:23   ` Stanislav Fomichev
2019-12-13 21:30     ` Alexei Starovoitov
2019-12-13 22:06       ` Stanislav Fomichev [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191213220600.GQ3105713@mini-arch \
    --to=sdf@fomichev.me \
    --cc=alexei.starovoitov@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=sdf@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.