From owner-freebsd-net@FreeBSD.ORG Wed Dec 19 23:02:31 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A40473A4 for ; Wed, 19 Dec 2012 23:02:31 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by mx1.freebsd.org (Postfix) with ESMTP id 5F4F98FC1B for ; Wed, 19 Dec 2012 23:02:31 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id c14so3791681ieb.0 for ; Wed, 19 Dec 2012 15:02:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ii3oapiDCDDApTf3f3HlkBkMDcn4HKY/a6iHWI0XFjQ=; b=WlzrXLuR3Q6hPbqk+ICZegS+VVbrINms6HpfjTt8ZW1+S8UMUQRHW36wO+yTHaNrVO V+fVXbnEYvo+VqM5nd3cnzOprL4FwwkUkR7pFlJeWCsHEyy55D3afFl5gJ/G1SttsUh2 IbHqqn5k1towik9vdguPUlGL75GaADbaPQlLYnWiEKHLebn7ZFWaCZlMj5Y8XgvFfspX 03Kzc256vVIXbrycrdjow3FwxLrsJVLSvK8XvgdCVsjUXFazAXXj8qnDMdXa9CYsAyi9 u2EF9hMnlqPvodePLaby3mWHRa5JDeuqWWKHUw75zc0jHC7KKyiaK50U0eVr++1uRMRf 1llw== X-Received: by 10.50.40.225 with SMTP id a1mr8916137igl.7.1355958144767; Wed, 19 Dec 2012 15:02:24 -0800 (PST) Received: from [192.168.1.73] ([208.85.112.101]) by mx.google.com with ESMTPS id gs6sm5349075igc.11.2012.12.19.15.02.22 (version=SSLv3 cipher=OTHER); Wed, 19 Dec 2012 15:02:23 -0800 (PST) Message-ID: <50D24774.80800@gmail.com> Date: Wed, 19 Dec 2012 18:02:12 -0500 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Vijay Singh Subject: Re: use of V_tcbinfo lock for TCP syncache References: <50D218BA.7080301@FreeBSD.org> <50D21C3B.8020803@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Navdeep Parhar X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 23:02:31 -0000 On 19/12/2012 4:01 PM, Vijay Singh wrote: >>> Holding the pcbinfo lock prevents races between syncache_socket() and >>> accept(). See rwatson's comment just above tcp_usr_accept. I noted >>> this too (the comment above tod->tod_offload_socket() in tcp_syncache.c) >>> back when I updated the TOE code in the kernel. >> er, I think I told you why tcp_usr_accept holds the pcbinfo lock, which >> wasn't your original question... :-) > But it helped. > > So I am thinking about trying a change where syncache_socket() would > call soalloc() first, get a socket, setup the inp, and then do a > (modified) sonewconn to place the socket in the listener's queue. > Robert's comment indicated that this would be a better way to > eliminate the race since we wouldn't need the pcblock when we make the > sonewconn call. > > Sure but syncache_expand() is entered with the tcbinfo already write locked which also protects the unlocking of the listening connection and the locking of the newly created socket. Around this part: /* * Socket is created in state SYN_RECEIVED. * Unlock the listen socket, lock the newly * created socket and update the tp variable. */ INP_WUNLOCK(inp); /* listen socket */ inp = sotoinpcb(so); INP_WLOCK(inp); /* new connection */ tp = intotcpcb(inp); Without the tcbinfo lock the new socket could be closed (getting a reset) which would put it in INP_TIMEWAIT or INP_DROPPED _after_ the check is made in tcp_usr_accept since there is a period of time where tcbinfo is not locked and the new socket inp is not locked either. I could be wrong but it seems that without the tcbinfo lock a lot could happen between the unlocking of the listen socket and the locking of the new one. Karim.