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]

Message-ID: <CAKgT0UcHky39E9Sxo7L_ZtOOx9uUNy5NdLa78C+oLeB2q21o+g@mail.gmail.com>
Date:	Mon, 9 May 2016 16:10:54 -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 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.

Like I said in the other email I did find two other issues.  First in
__gre6_xmit I think you want to set the inner protocol to "protocol",
not "proto".  Second is the issue with ip6_tnl_xmit stomping on
skb->transport_header.  The second one is the big one that is blocking
things badly right now.  That is the one that keeps me from doing
anything with any sort of offload as the headers are jumping around
out of order with the outer transport header having an offset that is
further in than the inner mac header.

I'd be fine with you submitting the whole set as one piece with the
other 11 patches you had just as long as we get those core pieces
fixed in the patch set.

- Alex