From owner-freebsd-current@FreeBSD.ORG Wed Jan 10 15:04:10 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 DB02016A492; Wed, 10 Jan 2007 15:04:09 +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 B407313C442; Wed, 10 Jan 2007 15:04:09 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 10 Jan 2007 07:04:09 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l0AF4991009174; Wed, 10 Jan 2007 07:04:09 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0AF49lb004347; Wed, 10 Jan 2007 07:04:09 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 07:04:09 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 07:04:08 -0800 Message-ID: <45A5004B.6090402@cisco.com> Date: Wed, 10 Jan 2007 10:03:39 -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: Robert Watson References: <20070107171034.GA13836@crodrigues.org> <45A139CF.3090909@cisco.com> <20070107185228.W41371@fledge.watson.org> <200701091426.36740.jhb@freebsd.org> <20070110142100.G52843@fledge.watson.org> In-Reply-To: <20070110142100.G52843@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jan 2007 15:04:09.0107 (UTC) FILETIME=[94648E30:01C734C8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3616; t=1168441449; x=1169305449; c=relaxed/simple; s=sjdkim6002; 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=7WvaGcY0em2zP1tznXw1n5fQe1wys82dnGQur2Vwz1M=; b=cPqUvOJ3db7FCFaHMCQy5eLLR0PBTkmLgFkocSCDiI2F2WuIo2IalZBG7OwfVvV9WNgEH8II Rf8RCm4/EKLA3SC44FwNy0ffDBcsKIDS9ALW0OTxdTSuyNm24vURgAFR; Authentication-Results: sj-dkim-6; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim6002 verified; ); Cc: Craig Rodrigues , freebsd-current@freebsd.org 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 15:04:10 -0000 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. This is needed since the one-2-many model can have connections establishing both in an active and passive mode at the same time. Since this lock is in place, we now get the warning where we never used to (I was finding a collision case when with an app that was not protected and ending up with two associations to the same place.. not good). Now, the problem is in the 1-2-1 model. This is a "tcp emulation' model and it does the sonewconn() stuff.. which ends up creating a PCB and thus does the hashinit(). The PCB is then put on the forming connections queue of the socket... and later an accept will pull it in. Now thinking about this, I might be able to NOT get the create lock on the socket if its a 1-2-1 model socket. This is because 1-2-1 models are not allowed to both create active and passive connections at the same time. However, if I do that, there is another danger. If I am a passive 1-2-1 socket, and the peer gets two cookies to me at the same exact moment (picture a network delay in one packet, a retrasmission of the other and they arrive at the same time). I am going to hit this case again and possibly create two associations at once. Thinking about this.. TCP may well have the same issue... of course it uses coarser grain locking so it might not see this. I can change things so we have this one hole.. as a known cavet.. its a disaster when you create two by the way... But it would be a rare occurrence.. Either that or.. I am back to my same two options hashinit_flags(...) or sctp_hashint(..) (which I have implemented for 6.0/6.1 and of course MAC which don't have these.. of course the main BSD tree never sees these since unifdef removes them). I can go with any of the above options.. however I would strongly not recommend the first .. since I think any rare thing.. will surely happen ;-0 R Robert Watson wrote: > > On Tue, 9 Jan 2007, John Baldwin wrote: > >> Either that or use an sx lock to close the pcb alloc race instead and >> don't hold mutexes while calling hashinit(). > > I think this is a good point -- I've generally been restructuring PCB > init functions so that they perform allocation up front before acquiring > locks in order to reduce lock contention on the table locks, which are > global and acquired in many other paths. This tends to simplify error > handling also. I'm not sure how well that applies in this case, > however. Certainly, we want to optimize for successful handling, since > malloc(9) failure is very unusual and occurs only in very exceptional > (and unfortunate) cases. A more likely failure is the exhaustion of the > zone limit on the pcb zone, which gates the overall allocation of memory > for the socket type, and should be the first memory type allocated when > setting up pcbs for this reason. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell)