netdev - Re: [PATCH v5 net-next 09/14] ip6_tun: Add infrastructure for doing encapsulation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALx6S35_EykxGm-S83cuCZFp6yaesqbLWgTxKQfdNr2WfBP8Ag@mail.gmail.com>
Date:	Mon, 16 May 2016 12:28:52 -0700
From:	Tom Herbert <tom@...bertland.com>
To:	Alexander Duyck <alexander.duyck@...il.com>
Cc:	David Miller <davem@...emloft.net>,
	Netdev <netdev@...r.kernel.org>, Kernel Team <kernel-team@...com>
Subject: Re: [PATCH v5 net-next 09/14] ip6_tun: Add infrastructure for doing encapsulation

On Mon, May 16, 2016 at 12:24 PM, Alexander Duyck
<alexander.duyck@...il.com> wrote:
> On Sun, May 15, 2016 at 4:42 PM, Tom Herbert <tom@...bertland.com> wrote:
>> Add encap_hlen and ip_tunnel_encap structure to ip6_tnl. Add functions
>> for getting encap hlen, setting up encap on a tunnel, performing
>> encapsulation operation.
>>
>> Signed-off-by: Tom Herbert <tom@...bertland.com>
>> ---
>>  include/net/ip6_tunnel.h  | 58 ++++++++++++++++++++++++++++++
>>  net/ipv4/ip_tunnel_core.c |  5 +++
>>  net/ipv6/ip6_tunnel.c     | 89 +++++++++++++++++++++++++++++++++++++++++------
>>  3 files changed, 141 insertions(+), 11 deletions(-)
>
> So a bisect is pointing to this patch as causing a regression in IPv6
> GRE throughput from 20 Gb/s to .04 Mb/s
>
> <...>
>
>> diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
>> index e79330f..9f0ea85 100644
>> --- a/net/ipv6/ip6_tunnel.c
>> +++ b/net/ipv6/ip6_tunnel.c
>> @@ -1010,7 +1010,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev, __u8 dsfield,
>>         struct dst_entry *dst = NULL, *ndst = NULL;
>>         struct net_device *tdev;
>>         int mtu;
>> -       unsigned int max_headroom = sizeof(struct ipv6hdr);
>> +       unsigned int max_headroom = sizeof(struct ipv6hdr) + t->hlen;
>>         int err = -1;
>>
>>         /* NBMA tunnel */
>> @@ -1063,7 +1063,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev, __u8 dsfield,
>>                                      t->parms.name);
>>                 goto tx_err_dst_release;
>>         }
>> -       mtu = dst_mtu(dst) - sizeof(*ipv6h);
>> +       mtu = dst_mtu(dst) - sizeof(*ipv6h) - t->hlen;
>>         if (encap_limit >= 0) {
>>                 max_headroom += 8;
>>                 mtu -= 8;
>
> So I am pretty sure this bit here is causing the regression.  Your skb
> already has a GRE header added and it is included in skb->len.  In the
> tests just below here you are comparing skb->len to mtu, but you now
> have the GRE header included twice so it is going to fail.  Odds are
> this should be t->encap_hlen, and not t->hlen.
>
Good catch! Fixing now...

> - Alex