From owner-freebsd-current@FreeBSD.ORG Wed Jan 10 19:53:12 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 1280C16A504; Wed, 10 Jan 2007 19:53:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id B20F813C465; Wed, 10 Jan 2007 19:53:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id l0AJqnx0087216; Wed, 10 Jan 2007 14:52:50 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Randall Stewart Date: Wed, 10 Jan 2007 14:31:57 -0500 User-Agent: KMail/1.9.4 References: <20070107171034.GA13836@crodrigues.org> <20070110142100.G52843@fledge.watson.org> <45A5004B.6090402@cisco.com> In-Reply-To: <45A5004B.6090402@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701101431.57695.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Wed, 10 Jan 2007 14:52:52 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2433/Wed Jan 10 13:28:34 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx 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 19:53:12 -0000 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(); 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). 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. -- John Baldwin