This is a note to let you know that I've just added the patch titled
net-gro: reset skb->truesize in napi_reuse_skb()
to the 3.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
net-gro-reset-skb-truesize-in-napi_reuse_skb.patch
and it can be found in the queue-3.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.
>From foo@baz Wed May 28 20:43:09 PDT 2014
From: Eric Dumazet <[email protected]>
Date: Thu, 3 Apr 2014 09:28:10 -0700
Subject: net-gro: reset skb->truesize in napi_reuse_skb()
From: Eric Dumazet <[email protected]>
[ Upstream commit e33d0ba8047b049c9262fdb1fcafb93cb52ceceb ]
Recycling skb always had been very tough...
This time it appears GRO layer can accumulate skb->truesize
adjustments made by drivers when they attach a fragment to skb.
skb_gro_receive() can only subtract from skb->truesize the used part
of a fragment.
I spotted this problem seeing TcpExtPruneCalled and
TcpExtTCPRcvCollapsed that were unexpected with a recent kernel, where
TCP receive window should be sized properly to accept traffic coming
from a driver not overshooting skb->truesize.
Signed-off-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/core/dev.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3898,6 +3898,7 @@ static void napi_reuse_skb(struct napi_s
skb->vlan_tci = 0;
skb->dev = napi->dev;
skb->skb_iif = 0;
+ skb->truesize = SKB_TRUESIZE(skb_end_offset(skb));
napi->skb = skb;
}
Patches currently in stable-queue which might be from [email protected] are
queue-3.10/ipv6-limit-mtu-to-65575-bytes.patch
queue-3.10/tcp_cubic-fix-the-range-of-delayed_ack.patch
queue-3.10/net-gro-reset-skb-truesize-in-napi_reuse_skb.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
