netdev - Re: [PATCH net-next] net-gro: Prepare GRO stack for the upcoming tunneling support

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: <1386703171.1516.203.camel@bwh-desktop.uk.level5networks.com>
Date:	Tue, 10 Dec 2013 19:19:31 +0000
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	"H.K. Jerry Chu" <hkchu@...gle.com>
CC:	Eric Dumazet <edumazet@...gle.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Or Gerlitz <ogerlitz@...lanox.com>, <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] net-gro: Prepare GRO stack for the upcoming
 tunneling support

On Sun, 2013-12-08 at 08:04 -0800, H.K. Jerry Chu wrote:
> From: Jerry Chu <hkchu@...gle.com>
> 
> This patch modifies the GRO stack to remove the assumption that
> only one IP hdr is present in the encapsulation chain. It avoids
> the use of ip_hdr()/ipv6_hdr() macro in IP's *_gro_receive()/
> *_gro_complete() functions because there may be more than one IP
> hdr present in the encapsulation chain when various flavors of IP
> tunneling support are added. By doing so it also allows multiple
> level, not just a single level (i.e., with only two IP hdrs like
> IP-in-IP) of encapsulation to be supported in the future.
> 
> With this patch, the GRO stack traversing now is mostly based on
> skb_gro_offset rather than special hdr offsets saved in skb (e.g.,
> skb->network_header, skb->transport_header,...) As a consequence
> all but the top layer (which is likely to be the transport layer)
> must have hdrs of the same length in order for a pkt to be
> considered for aggregation. Therefore when adding a new layer
> (e.g., for tunneling), one must check and skip flows (e.g., setting
> NAPI_GRO_CB(p)->same_flow to 0) that have a different hdr length.
> 
> Signed-off-by: H.K. Jerry Chu <hkchu@...gle.com>
> Suggested-by: Eric Dumazet <edumazet@...gle.com>
> Reviewed-by: Eric Dumazet <edumazet@...gle.com>
[...]
> --- a/net/ipv4/tcp_offload.c
> +++ b/net/ipv4/tcp_offload.c
[...]
> @@ -303,16 +308,16 @@ skip_csum:
>  	return tcp_gro_receive(head, skb);
>  }
>  
> -static int tcp4_gro_complete(struct sk_buff *skb)
> +static int tcp4_gro_complete(struct sk_buff *skb, int nhoff)

The offset should definitely be called thoff in this function.

[...]
> --- a/net/ipv6/ip6_offload.c
> +++ b/net/ipv6/ip6_offload.c
[...]
> @@ -198,25 +228,28 @@ static struct sk_buff **ipv6_gro_receive(struct sk_buff **head,
>  
>  		iph = ipv6_hdr(skb);
>  	}
> -
>  	NAPI_GRO_CB(skb)->proto = proto;
>  
>  	flush--;
> -	nlen = skb_network_header_len(skb);
> +	nlen = next_header - skb->network_header;
>  
>  	for (p = *head; p; p = p->next) {
> -		const struct ipv6hdr *iph2;
> +		struct ipv6hdr *iph2;

Why remove const here?

[...]
> -static int ipv6_gro_complete(struct sk_buff *skb)
> +static int ipv6_gro_complete(struct sk_buff *skb, int nhoff)
>  {
>  	const struct net_offload *ops;
> -	struct ipv6hdr *iph = ipv6_hdr(skb);
> +	struct ipv6hdr *iph = (struct ipv6hdr *)(skb->data + nhoff);
>  	int err = -ENOSYS;
>  
> -	iph->payload_len = htons(skb->len - skb_network_offset(skb) -
> -				 sizeof(*iph));
> +	iph->payload_len = htons(skb->len - nhoff - sizeof(*iph));
>  
>  	rcu_read_lock();
> -	ops = rcu_dereference(inet6_offloads[NAPI_GRO_CB(skb)->proto]);
> +
> +	nhoff += sizeof(*iph) + ipv6_exthdrs_len(iph, &ops);

Would be clearer as:
	int thoff;
	...
	thoff = nhoff + ...

>  	if (WARN_ON(!ops || !ops->callbacks.gro_complete))
>  		goto out_unlock;
>  
> -	err = ops->callbacks.gro_complete(skb);
> +	err = ops->callbacks.gro_complete(skb, nhoff);
>  
>  out_unlock:
>  	rcu_read_unlock();
> diff --git a/net/ipv6/tcpv6_offload.c b/net/ipv6/tcpv6_offload.c
> index 6d18157..a107ad6 100644
> --- a/net/ipv6/tcpv6_offload.c
> +++ b/net/ipv6/tcpv6_offload.c
> @@ -66,16 +66,16 @@ skip_csum:
>  	return tcp_gro_receive(head, skb);
>  }
>  
> -static int tcp6_gro_complete(struct sk_buff *skb)
> +static int tcp6_gro_complete(struct sk_buff *skb, int nhoff)
[...]

Same comment as for tcp4_gro_complete().

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html