netdev - Re: [PATCH net-next] ip6

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]

Date:	Mon, 9 May 2016 16:14:11 -0700
From:	Alexander Duyck <alexander.duyck@...il.com>
To:	Tom Herbert <tom@...bertland.com>
Cc:	David Miller <davem@...emloft.net>,
	Netdev <netdev@...r.kernel.org>, Kernel Team <kernel-team@...com>
Subject: Re: [PATCH net-next] ip6_gre: Fix MTU setting

On Mon, May 9, 2016 at 4:10 PM, Alexander Duyck
<alexander.duyck@...il.com> wrote:
> On Mon, May 9, 2016 at 3:49 PM, Tom Herbert <tom@...bertland.com> wrote:
>> On Mon, May 9, 2016 at 3:44 PM, Alexander Duyck
>> <alexander.duyck@...il.com> wrote:
>>> On Mon, May 9, 2016 at 3:28 PM, Tom Herbert <tom@...bertland.com> wrote:
>>>> In ip6gre_tnl_link_config set t->tun_len and t->hlen correctly for the
>>>> configuration. For hard_header_len and mtu calculation include
>>>> IPv6 header and encapsulation overhead.
>>>>
>>>> In ip6gre_tunnel_init_common set t->tun_len and t->hlen correctly for
>>>> the configuration. Revert to setting hard_header_len instead of
>>>> needed_headroom.
>>>>
>>>> Tested:
>>>>
>>>> ./ip link add name tun8 type ip6gretap remote \
>>>> 2401:db00:20:911a:face:0:27:0 local \
>>>> 2401:db00:20:911a:face:0:25:0 ttl 225
>>>>
>>>> Gives MTU of 1434. That is equal to 1500 - 40 - 14 - 4 - 8.
>>>>
>>>> ./ip link add name tun8 type ip6gretap remote \
>>>> 2401:db00:20:911a:face:0:27:0 local \
>>>> 2401:db00:20:911a:face:0:25:0 ttl 225 okey 123
>>>>
>>>> Gives MTU of 1430. That is equal to 1500 - 40 - 14 - 4 - 8 - 4.
>>>>
>>>> Signed-off-by: Tom Herbert <tom@...bertland.com>
>>>
>>> So this gives me the correct result now.  However we still need patch
>>> 3 / 11 from the set you submitted next week in order to be able to
>>> even transmit because the flags are otherwise mangled.
>>>
>>> Tested-by: Alexander Duyck <aduyck@...antis.com>
>>
>> Okay, I'll repost the flags patch as a standalone. Do you have any
>> other issues then in this path?
>
> This piece no.

Actually I just realized there are two other bits that need to be updated.

I just copied/pasted the below out of a text console so I am sure the
white-space formatting is wrong.  These two spots should be fixed as
well as they are using the wrong flag type.

diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index ec209f4d3312..ee62ec469ab3 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -343,7 +343,7 @@ static struct ip6_tnl *ip6gre_tunnel_locate(struct net *net,
                goto failed_free;

        /* Can use a lockless transmit, unless we generate output sequences */
-       if (!(nt->parms.o_flags & GRE_SEQ))
+       if (!(nt->parms.o_flags & TUNNEL_SEQ))
                dev->features |= NETIF_F_LLTX;

        dev_hold(dev);
@@ -1314,7 +1314,7 @@ static int ip6gre_newlink(struct net *src_net,
struct net_device *dev,
        dev->features           |= GRE6_FEATURES;
        dev->hw_features        |= GRE6_FEATURES;

-       if (!(nt->parms.o_flags & GRE_SEQ)) {
+       if (!(nt->parms.o_flags & TUNNEL_SEQ)) {
                /* TCP segmentation offload is not supported when we
                 * generate output sequences.
                 */