All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] ipv6: gro: fix PV6_GRO_CB(skb)->proto problem
@ 2012-10-08 19:38 Eric Dumazet
  2012-10-08 19:41 ` David Miller
  0 siblings, 1 reply; 4+ messages in thread
From: Eric Dumazet @ 2012-10-08 19:38 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, Herbert Xu

From: Eric Dumazet <edumazet@google.com>

It seems IPV6_GRO_CB(skb)->proto can be destroyed in skb_gro_receive()
if a new skb is allocated (to serve as an anchor for frag_list)

We copy NAPI_GRO_CB() only (not the IPV6 specific part) in :

*NAPI_GRO_CB(nskb) = *NAPI_GRO_CB(p);

So we leave IPV6_GRO_CB(nskb)->proto to 0 (fresh skb allocation) instead
of IPPROTO_TCP (6)

ipv6_gro_complete() isnt able to call ops->gro_complete()
[ tcp6_gro_complete() ]

Fix this by moving proto in NAPI_GRO_CB() and getting rid of
IPV6_GRO_CB

Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
---
 include/linux/netdevice.h |    3 +++
 net/ipv6/af_inet6.c       |   11 ++---------
 2 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 0a36fff..4b9035c 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1513,6 +1513,9 @@ struct napi_gro_cb {
 
 	/* jiffies when first packet was created/queued */
 	unsigned long age;
+
+	/* Used in ipv6_gro_receive() */
+	int	proto;
 };
 
 #define NAPI_GRO_CB(skb) ((struct napi_gro_cb *)(skb)->cb)
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index f757e3b..a974247 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -822,13 +822,6 @@ out:
 	return segs;
 }
 
-struct ipv6_gro_cb {
-	struct napi_gro_cb napi;
-	int proto;
-};
-
-#define IPV6_GRO_CB(skb) ((struct ipv6_gro_cb *)(skb)->cb)
-
 static struct sk_buff **ipv6_gro_receive(struct sk_buff **head,
 					 struct sk_buff *skb)
 {
@@ -874,7 +867,7 @@ static struct sk_buff **ipv6_gro_receive(struct sk_buff **head,
 		iph = ipv6_hdr(skb);
 	}
 
-	IPV6_GRO_CB(skb)->proto = proto;
+	NAPI_GRO_CB(skb)->proto = proto;
 
 	flush--;
 	nlen = skb_network_header_len(skb);
@@ -930,7 +923,7 @@ static int ipv6_gro_complete(struct sk_buff *skb)
 				 sizeof(*iph));
 
 	rcu_read_lock();
-	ops = rcu_dereference(inet6_protos[IPV6_GRO_CB(skb)->proto]);
+	ops = rcu_dereference(inet6_protos[NAPI_GRO_CB(skb)->proto]);
 	if (WARN_ON(!ops || !ops->gro_complete))
 		goto out_unlock;
 

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] ipv6: gro: fix PV6_GRO_CB(skb)->proto problem
  2012-10-08 19:38 [PATCH] ipv6: gro: fix PV6_GRO_CB(skb)->proto problem Eric Dumazet
@ 2012-10-08 19:41 ` David Miller
  2012-10-09 13:06   ` Eric Dumazet
  0 siblings, 1 reply; 4+ messages in thread
From: David Miller @ 2012-10-08 19:41 UTC (permalink / raw)
  To: eric.dumazet; +Cc: netdev, herbert

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 08 Oct 2012 21:38:50 +0200

> From: Eric Dumazet <edumazet@google.com>
> 
> It seems IPV6_GRO_CB(skb)->proto can be destroyed in skb_gro_receive()
> if a new skb is allocated (to serve as an anchor for frag_list)
> 
> We copy NAPI_GRO_CB() only (not the IPV6 specific part) in :
> 
> *NAPI_GRO_CB(nskb) = *NAPI_GRO_CB(p);
> 
> So we leave IPV6_GRO_CB(nskb)->proto to 0 (fresh skb allocation) instead
> of IPPROTO_TCP (6)
> 
> ipv6_gro_complete() isnt able to call ops->gro_complete()
> [ tcp6_gro_complete() ]
> 
> Fix this by moving proto in NAPI_GRO_CB() and getting rid of
> IPV6_GRO_CB
> 
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>

Applied and queued up for -stable, thanks Eric.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] ipv6: gro: fix PV6_GRO_CB(skb)->proto problem
  2012-10-08 19:41 ` David Miller
@ 2012-10-09 13:06   ` Eric Dumazet
  2012-10-09 16:44     ` David Miller
  0 siblings, 1 reply; 4+ messages in thread
From: Eric Dumazet @ 2012-10-09 13:06 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, herbert

On Mon, 2012-10-08 at 15:41 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 08 Oct 2012 21:38:50 +0200
> 
> > From: Eric Dumazet <edumazet@google.com>
> > 
> > It seems IPV6_GRO_CB(skb)->proto can be destroyed in skb_gro_receive()
> > if a new skb is allocated (to serve as an anchor for frag_list)
> > 
> > We copy NAPI_GRO_CB() only (not the IPV6 specific part) in :
> > 
> > *NAPI_GRO_CB(nskb) = *NAPI_GRO_CB(p);
> > 
> > So we leave IPV6_GRO_CB(nskb)->proto to 0 (fresh skb allocation) instead
> > of IPPROTO_TCP (6)
> > 
> > ipv6_gro_complete() isnt able to call ops->gro_complete()
> > [ tcp6_gro_complete() ]
> > 
> > Fix this by moving proto in NAPI_GRO_CB() and getting rid of
> > IPV6_GRO_CB
> > 
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > Cc: Herbert Xu <herbert@gondor.apana.org.au>
> 
> Applied and queued up for -stable, thanks Eric.

Hmm, it appears its a false alarm, you can remove it from stable
candidates.

*NAPI_GRO_CB(nskb) = *NAPI_GRO_CB(p);

was in fact redundant with the 

memcpy(new->cb, old->cb, sizeof(old->cb)); 

done in __copy_skb_header()

I'll send a patch to remove this double copy in net-next

Thanks

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] ipv6: gro: fix PV6_GRO_CB(skb)->proto problem
  2012-10-09 13:06   ` Eric Dumazet
@ 2012-10-09 16:44     ` David Miller
  0 siblings, 0 replies; 4+ messages in thread
From: David Miller @ 2012-10-09 16:44 UTC (permalink / raw)
  To: eric.dumazet; +Cc: netdev, herbert

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 09 Oct 2012 15:06:25 +0200

> Hmm, it appears its a false alarm, you can remove it from stable
> candidates.

Done.

> I'll send a patch to remove this double copy in net-next

Ok.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2012-10-09 16:44 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-08 19:38 [PATCH] ipv6: gro: fix PV6_GRO_CB(skb)->proto problem Eric Dumazet
2012-10-08 19:41 ` David Miller
2012-10-09 13:06   ` Eric Dumazet
2012-10-09 16:44     ` David Miller

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.