From owner-freebsd-net@FreeBSD.ORG Fri Feb 27 18:03:34 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 478FCA1A; Fri, 27 Feb 2015 18:03:34 +0000 (UTC) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B5C9ED4; Fri, 27 Feb 2015 18:03:34 +0000 (UTC) Received: by iecar1 with SMTP id ar1so32953736iec.0; Fri, 27 Feb 2015 10:03:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Niehm15p6jlbOyfLV4wsMIOpUljRi8NxSWU+DUXDF1Q=; b=L5bdsQzZs7zFtTTlzwmZMH0Vi9JjiCQn+EATkN8RRKaVYTLzQiKLVg3QlE3zsC5ngb 3IUWc7fraS38yKnKfi5726M8K8FzjePDMILRH11ZlZHWMp4r4chpwWtJO+KlEdNyDHqw DftW5cecU/RyZeZ74v3WM618HkOqakgCT3D7UBluaPjwhtIftCbXGQvQtyTmF7/mg65c wtOsH2pyJbm6AOjBpj1NZH3lQNcmVP/YB6lJmK8rwrxBf8TzxxUi1CZIOZlPru4uYUZj Ovhmk5vjKA3RhTwLlroLaXHQlYBhSuQnD0ld2G6A0apySweGT8WA2EuPPGR1lRw4IXXz MuWQ== MIME-Version: 1.0 X-Received: by 10.42.201.78 with SMTP id ez14mr17014873icb.22.1425060213391; Fri, 27 Feb 2015 10:03:33 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.17.66 with HTTP; Fri, 27 Feb 2015 10:03:33 -0800 (PST) In-Reply-To: <1425050565215.33356@netapp.com> References: <1421339375968.94209@netapp.com> <1421428048190.48193@netapp.com> <4258761.a1pROkzJe6@ralph.baldwin.cx> <1425050565215.33356@netapp.com> Date: Fri, 27 Feb 2015 10:03:33 -0800 X-Google-Sender-Auth: HDnpBR4QqQZqCQhJQE8KKLpVBuc Message-ID: Subject: Re: Accessing socket APIs soon after accept From: Adrian Chadd To: "Quattlebaum, Ryan" Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" , John Baldwin 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 18:03:34 -0000 Is this also a bug on -9 and -10? -a On 27 February 2015 at 07:22, Quattlebaum, Ryan wrote: > Thanks, John. That's almost exactly the approach we were considering. > > - Ryan Q > ________________________________________ > From: John Baldwin > 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