Date: Fri, 27 Feb 2015 15:22:43 +0000 From: "Quattlebaum, Ryan" <Ryan.Quattlebaum@netapp.com> To: John Baldwin <jhb@freebsd.org>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Cc: Adrian Chadd <adrian@freebsd.org> Subject: RE: Accessing socket APIs soon after accept Message-ID: <1425050565215.33356@netapp.com> In-Reply-To: <4258761.a1pROkzJe6@ralph.baldwin.cx> References: <1421339375968.94209@netapp.com> <CAJ-VmonYaAUior3aGBioVUvMPM1OMHJnHt7-rQgzMGQ4co4ATQ@mail.gmail.com> <1421428048190.48193@netapp.com>,<4258761.a1pROkzJe6@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks, John. That's almost exactly the approach we were considering.=0A= =0A= - Ryan Q=0A= ________________________________________=0A= From: John Baldwin <jhb@freebsd.org>=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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1425050565215.33356>