From patchwork Tue Dec 1 16:24:23 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Patrick McHardy X-Patchwork-Id: 39923 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by ozlabs.org (Postfix) with ESMTP id 4DFC4B6F1B for ; Wed, 2 Dec 2009 03:24:43 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754387AbZLAQYU (ORCPT ); Tue, 1 Dec 2009 11:24:20 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754384AbZLAQYT (ORCPT ); Tue, 1 Dec 2009 11:24:19 -0500 Received: from stinky.trash.net ([213.144.137.162]:46780 "EHLO stinky.trash.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754380AbZLAQYS (ORCPT ); Tue, 1 Dec 2009 11:24:18 -0500 Received: from [192.168.0.100] (unknown [78.42.107.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by stinky.trash.net (Postfix) with ESMTPSA id B3509B2C4B; Tue, 1 Dec 2009 17:24:23 +0100 (MET) Message-ID: <4B154337.8060702@trash.net> Date: Tue, 01 Dec 2009 17:24:23 +0100 From: Patrick McHardy User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: ben@bigfootnetworks.com CC: David Miller , netdev@vger.kernel.org Subject: Re: Bridge + Conntrack + SKB Recycle: Fragment Reassembly Errors References: <767BAF49E93AFB4B815B11325788A8ED45F0BA@L01SLCXDB03.calltower.com> <4AF999DE.9060206@trash.net> <20091121.110832.213888237.davem@davemloft.net> <4B0883FD.2090806@trash.net> <4B088600.8090209@trash.net> <767BAF49E93AFB4B815B11325788A8ED4B1FDC@L01SLCXDB03.calltower.com> In-Reply-To: <767BAF49E93AFB4B815B11325788A8ED4B1FDC@L01SLCXDB03.calltower.com> X-Enigmail-Version: 0.95.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org ben@bigfootnetworks.com wrote: >> Ben, please give this patch a try. > > I have not been able to recreate the issue after applying the patch, > which is great. Thanks for testing. > Is this the only case in which large-ish SKBs might be > recycled and cause the reassembly overflow? I'm not aware of any other cases at least. Dave, attached is the patch again with a proper changelog. commit d45f8b9ff2b7c1c5787348a39d3778931beca7e3 Author: Patrick McHardy Date: Tue Dec 1 17:19:14 2009 +0100 ip_fragment: also adjust skb->truesize for packets not owned by a socket When a large packet gets reassembled by ip_defrag(), the head skb accounts for all the fragments in skb->truesize. If this packet is refragmented again, skb->truesize is not re-adjusted to reflect only the head size since its not owned by a socket. If the head fragment then gets recycled and reused for another received fragment, it might exceed the defragmentation limits due to its large truesize value. skb_recycle_check() explicitly checks for linear skbs, so any recycled skb should reflect its true size in skb->truesize. Change ip_fragment() to also adjust the truesize value of skbs not owned by a socket. Reported-and-tested-by: Ben Menchaca Signed-off-by: Patrick McHardy diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c index b78e615..e34013a 100644 --- a/net/ipv4/ip_output.c +++ b/net/ipv4/ip_output.c @@ -503,8 +503,8 @@ int ip_fragment(struct sk_buff *skb, int (*output)(struct sk_buff *)) if (skb->sk) { frag->sk = skb->sk; frag->destructor = sock_wfree; - truesizes += frag->truesize; } + truesizes += frag->truesize; } /* Everything is OK. Generate! */