Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAADnVQK78PN8N6c6u_O2BAxdyXwH_HVYMV_x3oGgyfT50a6ymg@mail.gmail.com>
 <20220217070139.30028-1-lina.wang@mediatek.com> <41a3e6e4f9331c6a0a62fe838fc6f9084a5c89bc.camel@redhat.com>
In-Reply-To: <41a3e6e4f9331c6a0a62fe838fc6f9084a5c89bc.camel@redhat.com>
From:   Alexei Starovoitov <alexei.starovoitov@gmail.com>
Date:   Thu, 17 Feb 2022 09:05:08 -0800
Message-ID: <CAADnVQJEXOOH6--uA7BvFUPmXY42zeOQVweHmaMqkbj_g5TLqA@mail.gmail.com>
Subject: Re: [PATCH v3] net: fix wrong network header length
To:     Paolo Abeni <pabeni@redhat.com>
Cc:     Lina Wang <lina.wang@mediatek.com>,
        "David S . Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Matthias Brugger <matthias.bgg@gmail.com>,
        Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Andrii Nakryiko <andrii@kernel.org>,
        Network Development <netdev@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
        bpf <bpf@vger.kernel.org>,
        =?UTF-8?Q?Maciej_=C5=BBenczykowski?= <maze@google.com>,
        Willem de Bruijn <willemb@google.com>,
        Eric Dumazet <edumazet@google.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, Feb 17, 2022 at 12:45 AM Paolo Abeni <pabeni@redhat.com> wrote:
>
> Hello,
>
> On Thu, 2022-02-17 at 15:01 +0800, Lina Wang wrote:
> > On Wed, 2022-02-16 at 19:05 -0800, Alexei Starovoitov wrote:
> > > On Tue, Feb 15, 2022 at 11:37 PM Lina Wang <lina.wang@mediatek.com>
> > > wrote:
> > > >
> > > > When clatd starts with ebpf offloaing, and NETIF_F_GRO_FRAGLIST is
> > > > enable,
> > > > several skbs are gathered in skb_shinfo(skb)->frag_list. The first
> > > > skb's
> > > > ipv6 header will be changed to ipv4 after bpf_skb_proto_6_to_4,
> > > > network_header\transport_header\mac_header have been updated as
> > > > ipv4 acts,
> > > > but other skbs in frag_list didnot update anything, just ipv6
> > > > packets.
> > >
> > > Please add a test that demonstrates the issue and verifies the fix.
> >
> > I used iperf udp test to verify the patch, server peer enabled -d to de=
bug
> > received packets.
> >
> > 192.0.0.4 is clatd interface ip, corresponding ipv6 addr is
> > 2000:1:1:1:afca:1b1f:1a9:b367, server peer ip is 1.1.1.1,
> > whose ipv6 is 2004:1:1:1::101:101.
> >
> > Without the patch, when udp length 2840 packets received, iperf shows:
> > pcount 1 packet_count 0
> > pcount 27898727 packet_count 1
> > pcount 3 packet_count 27898727
> >
> > pcount should be 2, but is 27898727(0x1a9b367) , which is 20 bytes put
> > forward.
> >
> > 12:08:02.680299       Unicast to us 2004:1:1:1::101:101   2000:1:1:1:af=
ca:1b1f:1a9:b367 UDP 51196 =E2=86=92 5201 Len=3D2840
> > 0000   20 00 00 01 00 01 00 01 af ca 1b 1f 01 a9 b3 67   ipv6 dst addre=
ss
> > 0000   c7 fc 14 51 0b 20 c7 ab                           udp header
> > 0000   00 00 00 ab 00 0e f3 49 00 00 00 01 08 06 69 d2   00000001 is pc=
ount
> > 12:08:02.682084       Unicast to us   1.1.1.1                  192.0.0.=
4                UDP 51196 =E2=86=92 5201 Len=3D2840
> >
> > After applied the patch, there is no OOO, pcount acted in order.
>
> To clarify: Alexei is asking to add a test under:
>
> tools/testing/selftests/net/
>
> to cover this specific case. You can propbably extend the existing
> udpgro_fwd.sh.

Exactly.
I suspect the setup needs a bit more than just iperf udp test.
Does it need a specific driver and hw?
Can it be reproduced with veth or other virtual netdev?
Also commit talks about bpf_skb_proto_6_to_4.
So that bpf helper has to be somehow involved, but iperf udp test
says nothing about it.
Please craft a _complete_ selftest.

> Please explicitly CC people who gave feedback to previous iterations,
> it makes easier to track the discussion.
>
> /P
>