netdev - Re: [net-next PATCH 07/10] gre: Use inner_proto to obtain inner header protocol

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: <CAKgT0UcCCEKC7Gn2CqOR0i9O62NE7gV_w0dMmzbcrf9s2d5Adw@mail.gmail.com>
Date:	Sun, 7 Feb 2016 04:11:09 -0600
From:	Alexander Duyck <alexander.duyck@...il.com>
To:	Tom Herbert <tom@...bertland.com>
Cc:	Alexander Duyck <aduyck@...antis.com>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Edward Cree <ecree@...arflare.com>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [net-next PATCH 07/10] gre: Use inner_proto to obtain inner
 header protocol

On Sat, Feb 6, 2016 at 2:55 PM, Tom Herbert <tom@...bertland.com> wrote:
> On Fri, Feb 5, 2016 at 3:28 PM, Alexander Duyck <aduyck@...antis.com> wrote:
>> Instead of parsing headers to determine the inner protocol we can just pull
>> the value from inner_proto.
>>
>> Signed-off-by: Alexander Duyck <aduyck@...antis.com>
>> ---
>>  net/ipv4/gre_offload.c |    6 ++----
>>  1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/net/ipv4/gre_offload.c b/net/ipv4/gre_offload.c
>> index c15441b5ff61..003b0ebbcfdd 100644
>> --- a/net/ipv4/gre_offload.c
>> +++ b/net/ipv4/gre_offload.c
>> @@ -20,7 +20,6 @@ static struct sk_buff *gre_gso_segment(struct sk_buff *skb,
>>  {
>>         int tnl_hlen = skb_inner_mac_header(skb) - skb_transport_header(skb);
>>         struct sk_buff *segs = ERR_PTR(-EINVAL);
>> -       struct gre_base_hdr *greh;
>>         u16 mac_offset = skb->mac_header;
>>         __be16 protocol = skb->protocol;
>>         u16 mac_len = skb->mac_len;
>> @@ -48,15 +47,13 @@ static struct sk_buff *gre_gso_segment(struct sk_buff *skb,
>>         if (unlikely(!pskb_may_pull(skb, tnl_hlen)))
>>                 goto out;
>>
>> -       greh = (struct gre_base_hdr *)skb_transport_header(skb);
>> -
>>         /* setup inner skb. */
>> -       skb->protocol = greh->protocol;
>>         skb->encapsulation = 0;
>>         __skb_pull(skb, tnl_hlen);
>>         skb_reset_mac_header(skb);
>>         skb_set_network_header(skb, skb_inner_network_offset(skb));
>>         skb->mac_len = skb_inner_network_offset(skb);
>> +       skb->protocol = skb->inner_protocol;
>
> Is this going to be a problem if we try to perform GSO with nested
> encapsulations? (I suppose that's something not supported).

Right tunnels don't offload tunnels so there is no need to worry about
a tunnel nested in a tunnel.  We might get there someday, but I don't
see it happening any time soon because we would end up likely needing
yet another level of header pointers for middle mac, network, and
transport in such a case.

- Alex