summaryrefslogtreecommitdiff
path: root/include/linux
diff options
context:
space:
mode:
authorMichal Kubeček <mkubecek@suse.cz>2017-06-29 11:13:36 +0200
committerBen Hutchings <ben@decadent.org.uk>2017-09-15 18:30:16 +0100
commit96f30d3ea5241db59cc9ae9787df195e19f3d2bd (patch)
treeaa749f664be43c499e67d5ee70b4b0950832544f /include/linux
parent5a74f081200c711f516a4eeb729c6568438d974a (diff)
net: handle NAPI_GRO_FREE_STOLEN_HEAD case also in napi_frags_finish()
commit e44699d2c28067f69698ccb68dd3ddeacfebc434 upstream. Recently I started seeing warnings about pages with refcount -1. The problem was traced to packets being reused after their head was merged into a GRO packet by skb_gro_receive(). While bisecting the issue pointed to commit c21b48cc1bbf ("net: adjust skb->truesize in ___pskb_trim()") and I have never seen it on a kernel with it reverted, I believe the real problem appeared earlier when the option to merge head frag in GRO was implemented. Handling NAPI_GRO_FREE_STOLEN_HEAD state was only added to GRO_MERGED_FREE branch of napi_skb_finish() so that if the driver uses napi_gro_frags() and head is merged (which in my case happens after the skb_condense() call added by the commit mentioned above), the skb is reused including the head that has been merged. As a result, we release the page reference twice and eventually end up with negative page refcount. To fix the problem, handle NAPI_GRO_FREE_STOLEN_HEAD in napi_frags_finish() the same way it's done in napi_skb_finish(). Fixes: d7e8883cfcf4 ("net: make GRO aware of skb->head_frag") Signed-off-by: Michal Kubecek <mkubecek@suse.cz> Signed-off-by: David S. Miller <davem@davemloft.net> [bwh: Backported to 3.16: The necessary cleanup is just kmem_cache_free(), so don't bother adding a function for this.] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Diffstat (limited to 'include/linux')
0 files changed, 0 insertions, 0 deletions