From owner-freebsd-current@FreeBSD.ORG Wed Jan 10 20:04:18 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ADCB816A407; Wed, 10 Jan 2007 20:04:18 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.freebsd.org (Postfix) with ESMTP id 84E8A13C465; Wed, 10 Jan 2007 20:04:18 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 10 Jan 2007 12:04:18 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l0AK4H0I017438; Wed, 10 Jan 2007 12:04:17 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0AK41Iv006724; Wed, 10 Jan 2007 12:04:15 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 12:04:01 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 12:04:01 -0800 Message-ID: <45A54682.9040503@cisco.com> Date: Wed, 10 Jan 2007 15:03:14 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6 MIME-Version: 1.0 To: John Baldwin References: <20070107171034.GA13836@crodrigues.org> <20070110142100.G52843@fledge.watson.org> <45A5004B.6090402@cisco.com> <200701101431.57695.jhb@freebsd.org> In-Reply-To: <200701101431.57695.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jan 2007 20:04:01.0616 (UTC) FILETIME=[78C38D00:01C734F2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2011; t=1168459458; x=1169323458; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20Witness=20warning=20with=20SCTP |Sender:=20; bh=tsfnLmVrwv/Xa9qTsgsBxv3i4o3gI6g4PLH5n8bR8cc=; b=qU6cpI7AC63E+DCq/HvwBJ5OrS7wiOa+PIu12XX0oYdynpjDhL+ICm+xYAdIMoK0XN/11x21 B98IPS1tKDXDsuRhShWsQLqqza5ZCbVSkacnH4KgQ7t4rLo+r1enkERm; Authentication-Results: sj-dkim-8; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim8002 verified; ); Cc: Craig Rodrigues , freebsd-current@freebsd.org, Robert Watson Subject: Re: Witness warning with SCTP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2007 20:04:18 -0000 John: John Baldwin wrote: > On Wednesday 10 January 2007 10:03, Randall Stewart wrote: >> Robert/All: >> >> Ok, here is the deal... I have looked in a bit >> closer at this.. >> >> Here is what is happening... >> >> When a cookie arrives, we get a "create lock" on >> the socket this prevents the user on the same >> socket from creating a assoc at the same exact time. > > Can't you do a model like this: > > lock(); > if (need to create pcb) { > unlock(); > create_pcb(); // can sleep w/o holding lock > lock(); > if (someone else created the pcb) > free(pcb_I_just_created); > } > unlock(); The above is exactly what causes the race to occur.. There are several places where if we do that we end up with two TCB's under certain collision cases.. which can happen (I have a test app that gets it within a few hours :-() > > This is used in several places in the kernel to handle concurrent > object creation races. Speaking of the sx(9) man page there are > two things to note: > > 1) There are already patches to make sx(9) locks just as efficient > as mutexes in the common case (single atomic op), so that comment > is likely irrelevant (and probably shouldn't have existed in the > first place). ok > > 2) If you are already willing to sleep by calling hashinit() (which > can sleep in malloc()), then blocking on a sx lock is already fine > for the code where you are doing this. > I am NOT willing to sleep. the normal allocation of the PCB is done with a WAIT type option.. I had not realized that hashinit() did an allocation and could sleep.. thats the issue. I think the easiest way is to just go ahead and either have a specific hashinit() for sctp.. or redo hashinit to have a hashinit_flags() as we have been discussing.. and have the original hashinit() call that with WAIT.. and that would then allow a WAIT or NOWAIT ... R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell)