From owner-freebsd-current@FreeBSD.ORG Wed Jan 10 22:25:30 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 E5E0116A603; Wed, 10 Jan 2007 22:25:30 +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 B5E3A13C45A; Wed, 10 Jan 2007 22:25:27 +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 l0AMPHAA088417; Wed, 10 Jan 2007 17:25:17 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Randall Stewart Date: Wed, 10 Jan 2007 15:15:29 -0500 User-Agent: KMail/1.9.4 References: <20070107171034.GA13836@crodrigues.org> <200701101431.57695.jhb@freebsd.org> <45A54682.9040503@cisco.com> In-Reply-To: <45A54682.9040503@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701101515.30385.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 17:25:17 -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 22:25:31 -0000 On Wednesday 10 January 2007 15:03, Randall Stewart wrote: > 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 :-() Ah, you must have missed the part where it does: if (someone else created the pcb) { free(pcb I just created); use the other pcb; } :-P That is, explicitly handling the race. However: > 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. In that case a hashinit_flags() is the way to go I guess. What happens if the hashinit fails, connection dropped? -- John Baldwin