From owner-freebsd-stable@FreeBSD.ORG Tue Dec 6 14:51:53 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96EE9106566C for ; Tue, 6 Dec 2011 14:51:53 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 23D0D8FC0C for ; Tue, 6 Dec 2011 14:51:52 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RXwN1-0006RT-Pe for freebsd-stable@freebsd.org; Tue, 06 Dec 2011 15:51:47 +0100 Received: from ib-jtotz.ib.ic.ac.uk ([155.198.110.220]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Dec 2011 15:51:47 +0100 Received: from johannes by ib-jtotz.ib.ic.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Dec 2011 15:51:47 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Johannes Totz Date: Tue, 06 Dec 2011 14:51:33 +0000 Lines: 57 Message-ID: References: <4ECEF6FD.5050006@freebsd.org> <4ED077BF.10205@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ib-jtotz.ib.ic.ac.uk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: <4ED077BF.10205@freebsd.org> Subject: Re: TCP Reassembly Issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 14:51:53 -0000 On 26/11/2011 05:23, Lawrence Stewart wrote: > On 11/25/11 13:01, Lawrence Stewart wrote: >> On 11/24/11 18:02, Kris Bauer wrote: >>> Hello, >>> >>> I am currently experiencing an issue with FreeBSD 9.0-RC2 r227852 >>> where the >>> net.inet.tcp.reass.curesegments value is constantly increasing (and not >>> descreasing when there is nominal traffic with the box). It is causing >>> tcp >>> slowdowns as described with kern/155407: >>> >>> Exhausted net.inet.tcp.reass.maxsegments block recovering tcp session >>> (for >>> this socket and any other socket waiting for retransmited packets). >>> After >>> exhausted net.inet.tcp.reass.maxsegments allocation new entry in >>> tcp_reass >>> failed (for this socket and any other socket waiting for retransmited >>> packets). >>> >>> I have increased the reass.maxsegments value to 16384 to temporarily >>> avoid >>> the problem, but the cursegments number keeps rising and it seems it >>> will >>> occur again. >>> >>> Is this an issue that anyone else has seen? I can provide more >>> information >>> if need be. >> >> Thanks Kris, Raul and Stefan for the reports, I'll look into this. > > I think I've got it - a stupid 1 line logic bug. My apologies for > missing it when I reviewed the patch which introduced the bug (patch was > committed to head as r226113, MFCed to stable/9 as r226228). > > Due to some miscommunication, the initial patch was committed to and > MFCed from head much later than it should have been in the 9.0 release > cycle and instead of being included in the BETAs, didn't make it in > until 9.0-RC1 I believe i.e. only RC1 and RC2 should be experiencing the > issue. > > Could those who have reported the bug and are able to recompile their > kernel to test a patch please try the following and report back to the > list: > > http://people.freebsd.org/~lstewart/patches/misctcp/tcp_reass_plugzoneleak_10.x.r227986.patch > > > The patch is against head r227986 but will apply and work correctly for > 9.0 as well. Just a me-too. Patch applied cleanly and is working fine. Hehe... and I was blaming the Linux box at the other end of the connection :)