From owner-freebsd-net@FreeBSD.ORG Fri Feb 27 15:28:00 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 83E2564C; Fri, 27 Feb 2015 15:28:00 +0000 (UTC) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx143.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3255DABC; Fri, 27 Feb 2015 15:27:59 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.09,660,1418112000"; d="scan'208";a="26388997" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx143-out.netapp.com with ESMTP; 27 Feb 2015 07:22:44 -0800 Received: from HIOEXCMBX02-PRD.hq.netapp.com (10.122.105.35) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 27 Feb 2015 07:22:44 -0800 Received: from HIOEXCMBX02-PRD.hq.netapp.com ([fe80::98d0:d570:a8a3:beae]) by hioexcmbx02-prd.hq.netapp.com ([fe80::98d0:d570:a8a3:beae%21]) with mapi id 15.00.0995.031; Fri, 27 Feb 2015 07:22:43 -0800 From: "Quattlebaum, Ryan" To: John Baldwin , "freebsd-net@freebsd.org" Subject: RE: Accessing socket APIs soon after accept Thread-Topic: Accessing socket APIs soon after accept Thread-Index: AQHQMN+s1D+Mgs6QWka0EkIfHwtzNpzCBCMAgAD35iGAQmpFAP//ekh/ Date: Fri, 27 Feb 2015 15:22:43 +0000 Message-ID: <1425050565215.33356@netapp.com> References: <1421339375968.94209@netapp.com> <1421428048190.48193@netapp.com>,<4258761.a1pROkzJe6@ralph.baldwin.cx> In-Reply-To: <4258761.a1pROkzJe6@ralph.baldwin.cx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Adrian Chadd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 15:28:00 -0000 Thanks, John. That's almost exactly the approach we were considering.=0A= =0A= - Ryan Q=0A= ________________________________________=0A= From: John Baldwin =0A= Sent: Friday, February 27, 2015 10:20 AM=0A= To: freebsd-net@freebsd.org=0A= Cc: Quattlebaum, Ryan; Adrian Chadd=0A= Subject: Re: Accessing socket APIs soon after accept=0A= =0A= On Friday, January 16, 2015 05:07:28 PM Quattlebaum, Ryan wrote:=0A= > Hi, Adrian. Thanks for taking a look at this.=0A= >=0A= > We're using FreeBSD 8.2 and httpd-2.4.10 with arp-1.5.1 and apr-util-1.5.= 4.=0A= >=0A= > The problem we're seeing is pretty intermittent, so I hope this test case= =0A= > can shine a little bit of light on t= he=0A= > problem. We tried debugging this on our own by adding calls to=0A= > getsockname() right after the accept call (in=0A= > srclib/apr/network_io/unix/sockets.c: apr_socket_accept()) and logging th= e=0A= > output. That's where we saw invalid data.=0A= >=0A= > I took a look at the source code for the TCP syncache module and the acce= pt=0A= > syscall. It looks like the new child socket is available for the=0A= > application to accept after the call to sonewconn returns, but the addres= s=0A= > information isn't set until further down in the function. Wouldn't this= =0A= > open a window where an application could accept on a socket that the=0A= > syncache code isn't done configuring?=0A= =0A= This is a bug in 8.x it seems. It was fixed in HEAD in this commit:=0A= =0A= ------------------------------------------------------------------------=0A= r261242 | gnn | 2014-01-28 15:28:32 -0500 (Tue, 28 Jan 2014) | 10 lines=0A= =0A= Decrease lock contention within the TCP accept case by removing=0A= the INP_INFO lock from tcp_usr_accept. As the PR/patch states=0A= this was following the advice already in the code.=0A= See the PR below for a full disucssion of this change and its=0A= measured effects.=0A= =0A= PR: 183659=0A= Submitted by: Julian Charbon=0A= Reviewed by: jhb=0A= =0A= In particular, that commit changed the syncache code to not place the socke= t=0A= in the queue until the end of the function via soisconnected().=0A= =0A= You can probably merge the tcp_syncache.c portion of that change back to 8.= x=0A= without any ill effects and it should fix your problem.=0A= =0A= --=0A= John Baldwin=0A=