Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 Feb 2015 10:03:33 -0800
From:      Adrian Chadd <adrian@freebsd.org>
To:        "Quattlebaum, Ryan" <Ryan.Quattlebaum@netapp.com>
Cc:        "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, John Baldwin <jhb@freebsd.org>
Subject:   Re: Accessing socket APIs soon after accept
Message-ID:  <CAJ-VmonSgpDMiCTvdyaHpKX7ahLYAo9FZ0k1OfzK2TesfYLEvQ@mail.gmail.com>
In-Reply-To: <1425050565215.33356@netapp.com>
References:  <1421339375968.94209@netapp.com> <CAJ-VmonYaAUior3aGBioVUvMPM1OMHJnHt7-rQgzMGQ4co4ATQ@mail.gmail.com> <1421428048190.48193@netapp.com> <4258761.a1pROkzJe6@ralph.baldwin.cx> <1425050565215.33356@netapp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Is this also a bug on -9 and -10?



-a


On 27 February 2015 at 07:22, Quattlebaum, Ryan
<Ryan.Quattlebaum@netapp.com> wrote:
> Thanks, John. That's almost exactly the approach we were considering.
>
> - Ryan Q
> ________________________________________
> From: John Baldwin <jhb@freebsd.org>
> Sent: Friday, February 27, 2015 10:20 AM
> To: freebsd-net@freebsd.org
> Cc: Quattlebaum, Ryan; Adrian Chadd
> Subject: Re: Accessing socket APIs soon after accept
>
> On Friday, January 16, 2015 05:07:28 PM Quattlebaum, Ryan wrote:
>> Hi, Adrian. Thanks for taking a look at this.
>>
>> We're using FreeBSD 8.2 and httpd-2.4.10 with arp-1.5.1 and apr-util-1.5.4.
>>
>> The problem we're seeing is pretty intermittent, so I hope this test case
>> can                                      shine a little bit of light on the
>> problem. We tried debugging this on our own by adding calls to
>> getsockname() right after the accept call (in
>> srclib/apr/network_io/unix/sockets.c: apr_socket_accept()) and logging the
>> output. That's where we saw invalid data.
>>
>> I took a look at the source code for the TCP syncache module and the accept
>> syscall. It looks like the new child socket is available for the
>> application to accept after the call to sonewconn returns, but the address
>> information isn't set until further down in the function. Wouldn't this
>> open a window where an application could accept on a socket that the
>> syncache code isn't done configuring?
>
> This is a bug in 8.x it seems.  It was fixed in HEAD in this commit:
>
> ------------------------------------------------------------------------
> r261242 | gnn | 2014-01-28 15:28:32 -0500 (Tue, 28 Jan 2014) | 10 lines
>
> Decrease lock contention within the TCP accept case by removing
> the INP_INFO lock from tcp_usr_accept.  As the PR/patch states
> this was following the advice already in the code.
> See the PR below for a full disucssion of this change and its
> measured effects.
>
> PR:             183659
> Submitted by:   Julian Charbon
> Reviewed by:    jhb
>
> In particular, that commit changed the syncache code to not place the socket
> in the queue until the end of the function via soisconnected().
>
> You can probably merge the tcp_syncache.c portion of that change back to 8.x
> without any ill effects and it should fix your problem.
>
> --
> John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonSgpDMiCTvdyaHpKX7ahLYAo9FZ0k1OfzK2TesfYLEvQ>