From owner-freebsd-arch@FreeBSD.ORG Mon Oct 25 15:13:35 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 992F016A4CE; Mon, 25 Oct 2004 15:13:35 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BF9D43D1F; Mon, 25 Oct 2004 15:13:35 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i9PGBDgR030644; Mon, 25 Oct 2004 11:11:14 -0500 Date: Mon, 25 Oct 2004 11:11:13 -0500 (EST) From: Sam X-X-Sender: sah@athena To: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: 6.0 Witness squawk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2004 15:13:35 -0000 Hello, I'm almost finished porting my AoE (ATA over Ethernet) driver to 6.0 and have a question about a complaint witness is making. In general, is it ok to sleep with a mutex held? Specifically, it works like this in the driver. Each device struct has a mutex for guarding operations on it. Discovering devices is a two step process. First the device must respond to an AoE Query command, then it must respond to an ATA identify command. On the response to the latter, I grab the device mutex, examine the response and call disk_alloc() and disk_create(). Both of these functions call malloc with M_WAITOK, the latter triggers the witness message. In my situation, I don't really mind if I sleep with the mutex since I can't do any useful work with the device anyway. This does leave the possibility that the netisr for AoE could sleep. Thoughts? Cheers, Sam From owner-freebsd-arch@FreeBSD.ORG Mon Oct 25 15:26:18 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 007E216A4CF; Mon, 25 Oct 2004 15:26:18 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i9PFQHvL085595; Mon, 25 Oct 2004 11:26:17 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i9PFQGPu085594; Mon, 25 Oct 2004 11:26:16 -0400 (EDT) (envelope-from green) Date: Mon, 25 Oct 2004 11:26:15 -0400 From: Brian Fundakowski Feldman To: Sam Message-ID: <20041025152615.GQ1072@green.homeunix.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: 6.0 Witness squawk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2004 15:26:18 -0000 On Mon, Oct 25, 2004 at 11:11:13AM -0500, Sam wrote: > Hello, > > I'm almost finished porting my AoE (ATA over Ethernet) > driver to 6.0 and have a question about a complaint witness > is making. > > In general, is it ok to sleep with a mutex held? > > Specifically, it works like this in the driver. > Each device struct has a mutex for guarding > operations on it. Discovering devices is a two > step process. First the device must respond to > an AoE Query command, then it must respond to > an ATA identify command. On the response to > the latter, I grab the device mutex, examine > the response and call disk_alloc() and disk_create(). > > Both of these functions call malloc with M_WAITOK, > the latter triggers the witness message. > > In my situation, I don't really mind if I sleep > with the mutex since I can't do any useful work > with the device anyway. > > This does leave the possibility that the netisr > for AoE could sleep. > > Thoughts? If you can't do any useful work, why do you have the mutex? Leave the mutex operations for when exclusivity _is_necessary_, after the major parts of initialization. No, it's not okay to sleep with a mutex held -- it must be dropped a la msleep/cv/whatever. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-arch@FreeBSD.ORG Mon Oct 25 15:48:36 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F59716A4CE; Mon, 25 Oct 2004 15:48:36 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9766943D39; Mon, 25 Oct 2004 15:48:35 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i9PGkEmg030911; Mon, 25 Oct 2004 11:46:15 -0500 Date: Mon, 25 Oct 2004 11:46:14 -0500 (EST) From: Sam X-X-Sender: sah@athena To: Brian Fundakowski Feldman In-Reply-To: <20041025152615.GQ1072@green.homeunix.org> Message-ID: References: <20041025152615.GQ1072@green.homeunix.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-current@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: 6.0 Witness squawk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2004 15:48:36 -0000 > On Mon, Oct 25, 2004 at 11:11:13AM -0500, Sam wrote: >> Hello, >> >> I'm almost finished porting my AoE (ATA over Ethernet) >> driver to 6.0 and have a question about a complaint witness >> is making. >> >> In general, is it ok to sleep with a mutex held? >> >> Specifically, it works like this in the driver. >> Each device struct has a mutex for guarding >> operations on it. Discovering devices is a two >> step process. First the device must respond to >> an AoE Query command, then it must respond to >> an ATA identify command. On the response to >> the latter, I grab the device mutex, examine >> the response and call disk_alloc() and disk_create(). >> >> Both of these functions call malloc with M_WAITOK, >> the latter triggers the witness message. >> >> In my situation, I don't really mind if I sleep >> with the mutex since I can't do any useful work >> with the device anyway. >> >> This does leave the possibility that the netisr >> for AoE could sleep. >> >> Thoughts? > > If you can't do any useful work, why do you have the mutex? Leave > the mutex operations for when exclusivity _is_necessary_, after the > major parts of initialization. No, it's not okay to sleep with a > mutex held -- it must be dropped a la msleep/cv/whatever. There are three entry points into the driver. 1) The disk layer 2) the netisr routine 3) the rexmit timer. The mutex is to keep them from stepping on each other. At this stage, the rexmit timer is active. I'll hack in some state so I can release the mutex. Thanks for your helpful response. Sam From owner-freebsd-arch@FreeBSD.ORG Mon Oct 25 15:52:11 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1DCF16A4CE; Mon, 25 Oct 2004 15:52:11 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7587E43D41; Mon, 25 Oct 2004 15:52:11 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 3D1955314; Mon, 25 Oct 2004 17:52:10 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 765BB5310; Mon, 25 Oct 2004 17:52:03 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 45733B85E; Mon, 25 Oct 2004 17:52:03 +0200 (CEST) To: Sam References: From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Mon, 25 Oct 2004 17:52:03 +0200 In-Reply-To: (sah@softcardsystems.com's message of "Mon, 25 Oct 2004 11:11:13 -0500 (EST)") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.64 cc: freebsd-current@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: 6.0 Witness squawk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2004 15:52:11 -0000 Sam writes: > In general, is it ok to sleep with a mutex held? No, never. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Mon Oct 25 16:05:22 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD74816A4CF; Mon, 25 Oct 2004 16:05:22 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F60D43D39; Mon, 25 Oct 2004 16:05:22 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 618435316; Mon, 25 Oct 2004 18:05:21 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id D76FD5314; Mon, 25 Oct 2004 18:05:11 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id B9C5BB85E; Mon, 25 Oct 2004 18:05:11 +0200 (CEST) To: Sam References: <20041025152615.GQ1072@green.homeunix.org> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Mon, 25 Oct 2004 18:05:11 +0200 In-Reply-To: (sah@softcardsystems.com's message of "Mon, 25 Oct 2004 11:46:14 -0500 (EST)") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.64 cc: freebsd-current@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: 6.0 Witness squawk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2004 16:05:22 -0000 Sam writes: > There are three entry points into the driver. 1) The disk > layer 2) the netisr routine 3) the rexmit timer. AFAIK, if the code that calls malloc() can be reached from 2) or 3), you're not allowed to use M_WAITOK. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Mon Oct 25 16:24:48 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 075D316A4CE; Mon, 25 Oct 2004 16:24:48 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FE1243D54; Mon, 25 Oct 2004 16:24:47 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i9PHML2W031149; Mon, 25 Oct 2004 12:22:21 -0500 Date: Mon, 25 Oct 2004 12:22:21 -0500 (EST) From: Sam X-X-Sender: sah@athena To: =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-current@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: 6.0 Witness squawk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2004 16:24:48 -0000 > Sam writes: >> There are three entry points into the driver. 1) The disk >> layer 2) the netisr routine 3) the rexmit timer. > > AFAIK, if the code that calls malloc() can be reached from 2) or 3), > you're not allowed to use M_WAITOK. Hm. If that's true then I've either got to petition you fellas to change disk_alloc(), disk_create(), and disk_destroy() to use M_NOWAIT or schedule a callback where these calls can be handled properly. Thoughts about either approach? Sam From owner-freebsd-arch@FreeBSD.ORG Mon Oct 25 17:14:48 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 033CA16A4CE for ; Mon, 25 Oct 2004 17:14:48 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBF1243D1F for ; Mon, 25 Oct 2004 17:14:47 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 3064 invoked from network); 25 Oct 2004 17:14:47 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail2.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 25 Oct 2004 17:14:47 -0000 Received: from hydrogen.funkthat.com (atmzeb@localhost.funkthat.com [127.0.0.1])i9PHEklb069894; Mon, 25 Oct 2004 10:14:46 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i9PHEj6a069893; Mon, 25 Oct 2004 10:14:45 -0700 (PDT) Date: Mon, 25 Oct 2004 10:14:45 -0700 From: John-Mark Gurney To: Sam Message-ID: <20041025171445.GE22681@funkthat.com> Mail-Followup-To: Sam , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , freebsd-current@freebsd.org, freebsd-arch@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= cc: freebsd-current@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: 6.0 Witness squawk X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2004 17:14:48 -0000 Sam wrote this message on Mon, Oct 25, 2004 at 12:22 -0500: > >Sam writes: > >>There are three entry points into the driver. 1) The disk > >>layer 2) the netisr routine 3) the rexmit timer. > > > >AFAIK, if the code that calls malloc() can be reached from 2) or 3), > >you're not allowed to use M_WAITOK. > > Hm. If that's true then I've either got to petition you > fellas to change disk_alloc(), disk_create(), and disk_destroy() > to use M_NOWAIT or schedule a callback where these calls > can be handled properly. > > Thoughts about either approach? I'd go and do a callback.. You can do that using the generic taskqueue setup for this task... It's not an event that happens often, so the delay to schedule and execute won't be significant... Changing disk_alloc and friends to use M_NOWAIT would have significant implications to other code... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Tue Oct 26 05:19:05 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A26E716A4CE; Tue, 26 Oct 2004 05:19:05 +0000 (GMT) Received: from v6.hitachi.co.jp (galilei.v6.hitachi.co.jp [133.145.167.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EC4843D39; Tue, 26 Oct 2004 05:19:04 +0000 (GMT) (envelope-from suz@crl.hitachi.co.jp) Received: from flora210w.uki-uki.net (localhost [IPv6:::1]) by v6.hitachi.co.jp (8.12.11/8.12.11) with ESMTP id i9Q5J1Oc046258; Tue, 26 Oct 2004 14:19:02 +0900 (JST) (envelope-from suz@crl.hitachi.co.jp) Date: Tue, 26 Oct 2004 14:19:02 +0900 Message-ID: From: SUZUKI Shinsuke To: peter.lei@ieee.org X-cite: xcite 1.33 In-Reply-To: <4179ACB8.4020108@ieee.org> References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> <20041021213248.223cab2c.molter@tin.it> <4179ACB8.4020108@ieee.org> User-Agent: Wanderlust/2.11.32 (Wonderwall) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Network Systems Research Dept., Central Research Laboratory, Hitachi, Ltd, Japan MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org cc: andre@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: SCTP in KAME / Re: Removing T/TCP and replacing it withsomething simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 05:19:05 -0000 >>>>> On Fri, 22 Oct 2004 19:58:32 -0500 >>>>> peter.lei@ieee.org(Peter Lei) said: > While the SCTP API hasn't gone through last call, it's fairly > stable and we have both "converted" many applications from TCP > to SCTP using the sockets API, as well as had portability between > the KAME SCTP stack and the linux stack for some test applications > used at the last interop event (except for the standard sockets > issues that one runs into even for TCP like no sin_length field > in the sockaddr struct). > I'm not aware of any KAME SNAP compilation failures w/and w/o SCTP. > The major changes to our SCTP code when it gets committed into KAME > has been that of code format/style. What I found was the following two issues. Although these two are technically quite trivial, what I was fearing was a lack of report to KAME, since this may mean a lack of KAME-SCTP users. - inconsistency between KAME specific kernel code and SCTP leads to an kernel compilation error. Of course, it's a technically trivial bug and our own bug. - including SCTP in getaddrinfo() causes 'configure' script error in many ports applications. This is also a trivial problem, and maybe specific to KAME SCTP. And some of such ports are already fixed when I encounter this problem. (e.g. http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/files/patch-configure.diff?r1=1.7&r2=1.8) But now I understand that lack of report does not mean a lack of testing users (since SCTP-lovers seems communicating directly to your team). So I can be much more optimistic now, and don't object to merging it into -current, since such trivial bugs can be fixed easily in -current. (I myself haven't tested SCTP very well, so I cannot comment on its stability itself. But at least, SCTP does not seem to affect the behavior of other protocols) Thanks and sorry if you feel my previous comments were insulting... ---- SUZUKI, Shinsuke @ KAME Project From owner-freebsd-arch@FreeBSD.ORG Tue Oct 26 10:42:02 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD64B16A4CE; Tue, 26 Oct 2004 10:42:02 +0000 (GMT) Received: from stewart.chicago.il.us (dpc674425142.direcpc.com [67.44.25.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3606D43D3F; Tue, 26 Oct 2004 10:42:00 +0000 (GMT) (envelope-from randall@stewart.chicago.il.us) Received: from stewart.chicago.il.us (localhost [127.0.0.1]) i9QAfaT8007280; Tue, 26 Oct 2004 06:41:42 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <417E2985.2070609@stewart.chicago.il.us> Date: Tue, 26 Oct 2004 06:40:05 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SUZUKI Shinsuke References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> <20041021213248.223cab2c.molter@tin.it> <4179ACB8.4020108@ieee.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: peter.lei@ieee.org cc: freebsd-net@freebsd.org cc: andre@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: SCTP in KAME / Re: Removing T/TCP and replacing itwithsomething simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 10:42:03 -0000 SUZUKI Shinsuke wrote: >>>>>>On Fri, 22 Oct 2004 19:58:32 -0500 >>>>>>peter.lei@ieee.org(Peter Lei) said: > > >>While the SCTP API hasn't gone through last call, it's fairly >>stable and we have both "converted" many applications from TCP >>to SCTP using the sockets API, as well as had portability between >>the KAME SCTP stack and the linux stack for some test applications >>used at the last interop event (except for the standard sockets >>issues that one runs into even for TCP like no sin_length field >>in the sockaddr struct). >>I'm not aware of any KAME SNAP compilation failures w/and w/o SCTP. >>The major changes to our SCTP code when it gets committed into KAME >>has been that of code format/style. > > > What I found was the following two issues. Although these two are > technically quite trivial, what I was fearing was a lack of report to > KAME, since this may mean a lack of KAME-SCTP users. > > - inconsistency between KAME specific kernel code and SCTP leads > to an kernel compilation error. > Of course, it's a technically trivial bug and our own bug. > > - including SCTP in getaddrinfo() causes 'configure' script error > in many ports applications. > This is also a trivial problem, and maybe specific to KAME SCTP. > And some of such ports are already fixed when I encounter this > problem. > (e.g. http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/files/patch-configure.diff?r1=1.7&r2=1.8) > > But now I understand that lack of report does not mean a lack of > testing users (since SCTP-lovers seems communicating directly to your > team). So I can be much more optimistic now, and don't object to > merging it into -current, since such trivial bugs can be fixed easily > in -current. (I myself haven't tested SCTP very well, so I cannot > comment on its stability itself. But at least, SCTP does not seem to > affect the behavior of other protocols) > > Thanks and sorry if you feel my previous comments were insulting... > ---- > Suzuki-san: None of us on the SCTP team took your comments as insults ... we all want software with no bugs.. but it is perfectly understandable that if you don't get any bug reports you would feel no one is using it... As to compilation errors... it is difficult for me since when I prepare a patch of course I compile it but often times it takes many weeks for one of the KAME team to find the time to apply it.. this then causes a possiblity that some other changes made by KAME will make it uncompilable... or for that matter a change that KAME makes can cause SCTP not to compile and I would not have a chance to see such an issue... I am sorry I cannot help more :-0 Today I will finish running down a couple of "extra-shutdown's" and a case where no HB happens... (these are my reported bugs that are left.. nothing serious ... just a couple of strange behaviors)... Once I am done with that I can do my performance testing and then on to loading 6.0 :-D R -- Randall Stewart 803-345-0369 815-342-5222(cell) From owner-freebsd-arch@FreeBSD.ORG Tue Oct 26 14:45:03 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E01816A4CE; Tue, 26 Oct 2004 14:45:03 +0000 (GMT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B93643D39; Tue, 26 Oct 2004 14:45:03 +0000 (GMT) (envelope-from peter.lei@ieee.org) Received: from [192.168.0.203] (229-pool1.ras11.ilchi.alerondial.net[206.148.80.229]) by comcast.net (sccrmhc13) with ESMTP id <20041026144452016001rah7e> (Authid: peterlei); Tue, 26 Oct 2004 14:44:54 +0000 Message-ID: <417E62D9.2080807@ieee.org> Date: Tue, 26 Oct 2004 09:44:41 -0500 From: Peter Lei User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SUZUKI Shinsuke References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> <20041021213248.223cab2c.molter@tin.it> <4179ACB8.4020108@ieee.org> In-Reply-To: X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010709090807020301090904" cc: freebsd-net@freebsd.org cc: Randall Stewart cc: andre@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: SCTP in KAME / Re: Removing T/TCP and replacing itwithsomething simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 14:45:03 -0000 This is a cryptographically signed message in MIME format. --------------ms010709090807020301090904 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit SUZUKI Shinsuke wrote: >>>>>>On Fri, 22 Oct 2004 19:58:32 -0500 >>>>>>peter.lei@ieee.org(Peter Lei) said: > > >>While the SCTP API hasn't gone through last call, it's fairly >>stable and we have both "converted" many applications from TCP >>to SCTP using the sockets API, as well as had portability between >>the KAME SCTP stack and the linux stack for some test applications >>used at the last interop event (except for the standard sockets >>issues that one runs into even for TCP like no sin_length field >>in the sockaddr struct). >>I'm not aware of any KAME SNAP compilation failures w/and w/o SCTP. >>The major changes to our SCTP code when it gets committed into KAME >>has been that of code format/style. > > > What I found was the following two issues. Although these two are > technically quite trivial, what I was fearing was a lack of report to > KAME, since this may mean a lack of KAME-SCTP users. > > - inconsistency between KAME specific kernel code and SCTP leads > to an kernel compilation error. > Of course, it's a technically trivial bug and our own bug. This might be due to the fact that the SCTP CVS repository code is sometimes more up-to-date than the KAME one, so we can get out of sync. Randy releases patch kits based on some point in the KAME repository and we know it compiles (and runs) fine at that point, but by the time it is committed into the KAME repository, things may have changed. > - including SCTP in getaddrinfo() causes 'configure' script error > in many ports applications. > This is also a trivial problem, and maybe specific to KAME SCTP. > And some of such ports are already fixed when I encounter this > problem. > (e.g. http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/files/patch-configure.diff?r1=1.7&r2=1.8) Ok... I understand what you mean by compile errors now. I haven't done too much with existing apps but haven't run into this at all much yet. > But now I understand that lack of report does not mean a lack of > testing users (since SCTP-lovers seems communicating directly to your > team). So I can be much more optimistic now, and don't object to > merging it into -current, since such trivial bugs can be fixed easily > in -current. (I myself haven't tested SCTP very well, so I cannot > comment on its stability itself. But at least, SCTP does not seem to > affect the behavior of other protocols) I understand... the lack of bugs filed might lead you to believe the code isn't being used at all. > Thanks and sorry if you feel my previous comments were insulting... No, no... not at all. I just wanted to be sure that people know that the stack is indeed being used and that people are finding bugs and we are fixing them :-) regards, --peter > ---- > SUZUKI, Shinsuke @ KAME Project > --------------ms010709090807020301090904 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII7TCC AtEwggI6oAMCAQICAwvwrTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwMzE3MjE1NjMzWhcNMDUwMzE3MjE1NjMz WjBEMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSEwHwYJKoZIhvcNAQkBFhJw ZXRlci5sZWlAaWVlZS5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDX4PR3 QP+rgEBZtv1Q4YhKjRXUZQSk+9xNzesbK7pyirmUxKnm209ZGibDUAb/yC0ghvl3GbvNv/72 cyfC7JVjiABrDxY19L9mRGLKzjlK/bgBPY8SIu4blM/RtyabN4CdYk24LoGPHuLLkJIvvvQR LG0IJIfP8zvoHy0UGzyXOM/S4msxF1zDpBu7lYMe4Dpu5O9uaE2j1G/jswVmO2KMyQmffOGx 0Mw18tiGNMWkjMAwSJnXO2VSHzvh+I3OM71ReFo9ET2TtiXzqdDM5z0/LTsIyy1vP4Ib3Co9 xZNTe6JqVk2BsH7EZKPxi+oD7f/HctNWTZk0sesgba7D97jLAgMBAAGjLzAtMB0GA1UdEQQW MBSBEnBldGVyLmxlaUBpZWVlLm9yZzAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AB86WuVOs/pHjC4SPdbKb+obiQZVqR813FD3JcW+stkaZQHTPHoln/SYRd3TZcZIXageyme6 f5Gl3lOsamSUrtkov5u6B0vvtuDuMQH7deh1ARTQfC+R3hv29vVQ+uSPlLo/AGWaPcW030NW Bp96xBIESmHBMWGuYWkxMDHII/R+MIIC0TCCAjqgAwIBAgIDC/CtMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDAz MTcyMTU2MzNaFw0wNTAzMTcyMTU2MzNaMEQxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBN ZW1iZXIxITAfBgkqhkiG9w0BCQEWEnBldGVyLmxlaUBpZWVlLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBANfg9HdA/6uAQFm2/VDhiEqNFdRlBKT73E3N6xsrunKKuZTE qebbT1kaJsNQBv/ILSCG+XcZu82//vZzJ8LslWOIAGsPFjX0v2ZEYsrOOUr9uAE9jxIi7huU z9G3Jps3gJ1iTbgugY8e4suQki++9BEsbQgkh8/zO+gfLRQbPJc4z9LiazEXXMOkG7uVgx7g Om7k725oTaPUb+OzBWY7YozJCZ984bHQzDXy2IY0xaSMwDBImdc7ZVIfO+H4jc4zvVF4Wj0R PZO2JfOp0MznPT8tOwjLLW8/ghvcKj3Fk1N7ompWTYGwfsRko/GL6gPt/8dy01ZNmTSx6yBt rsP3uMsCAwEAAaMvMC0wHQYDVR0RBBYwFIEScGV0ZXIubGVpQGllZWUub3JnMAwGA1UdEwEB /wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAHzpa5U6z+keMLhI91spv6huJBlWpHzXcUPclxb6y 2RplAdM8eiWf9JhF3dNlxkhdqB7KZ7p/kaXeU6xqZJSu2Si/m7oHS++24O4xAft16HUBFNB8 L5HeG/b29VD65I+Uuj8AZZo9xbTfQ1YGn3rEEgRKYcExYa5haTEwMcgj9H4wggM/MIICqKAD AgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZy ZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHy v1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsY Pge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0T AQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20v VGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQe MBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD 6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZ GwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECAwvwrTAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDEwMjYxNDQ0NDFaMCMGCSqGSIb3DQEJ BDEWBBS6dbbvBCwqYEOWb9rrC2lY3V5WAjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg SXNzdWluZyBDQQIDC/CtMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwvwrTANBgkqhkiG9w0BAQEFAASCAQAY+p+f t0w3mRIyWAeyB+CmcInZMTHpm2By+r2wf9t/5T+/5dYtBGMMB5s9MIOkI9AOHAz8b+ZVFLSb Dliw/hNaX7CsWfHNlvOYZfTivVp6oJ15hvX4AF/9YfITlgi+1W57PLkDVEJabtXBXfc0tdM9 6Jewjwh9OXqo57ojSQ7eQKZ2loUDicLuLfWH4f3DtaEwysXnE5wDfYp9tII+s/V9f36Fb+Mv kDYtvqgBlg7JT74rrykaBHnOo6ec+sPvdZKpjFYPbUbHfJRjm7mfuhZC/sSQQWM4dyOBLNlc mmcNYGXQhCvAJtfEnkQvDhytWO9nStDFcWYc4J07E68bldr3AAAAAAAA --------------ms010709090807020301090904-- From owner-freebsd-arch@FreeBSD.ORG Tue Oct 26 16:22:55 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0F0816A4CE for ; Tue, 26 Oct 2004 16:22:55 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 871A943D49 for ; Tue, 26 Oct 2004 16:22:55 +0000 (GMT) (envelope-from john@baldwin.cx) Received: (qmail 11186 invoked from network); 26 Oct 2004 16:22:55 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 26 Oct 2004 16:22:54 -0000 Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i9QGMpOs007631; Tue, 26 Oct 2004 12:22:51 -0400 (EDT) (envelope-from john@baldwin.cx) Received: from zion.baldwin.cx (localhost [127.0.0.1]) by zion.baldwin.cx (8.12.10/8.12.10) with ESMTP id i9QGMp8h015020; Tue, 26 Oct 2004 12:22:51 -0400 (EDT) (envelope-from john@zion.baldwin.cx) Received: by zion.baldwin.cx (8.12.10/8.12.10/Submit) id i9QGMoEL015019; Tue, 26 Oct 2004 12:22:50 -0400 (EDT) (envelope-from john) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Tue, 26 Oct 2004 11:53:12 -0400 User-Agent: KMail/1.6 References: <59920.1098481368@critter.freebsd.dk> In-Reply-To: <59920.1098481368@critter.freebsd.dk> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200410261153.12982.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Poul-Henning Kamp Subject: Re: REVIEW: handling kldload/kldunload of GEOM classes properly. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 16:22:56 -0000 On Friday 22 October 2004 05:42 pm, Poul-Henning Kamp wrote: > There are a number of system calls which starts events running in > GEOM and which for consistency should not return to userland until > those events have completed and GEOM has settled down. > > The typical example would be a shell-script doing: > > kldload md > mdconfig bla bla > > > Examples of such syscalls are: > > open(2) & close(2): can cause spoils and retastes > > mount(2)/umount(2): acts as open/close. > > (any other syscall doing a VOP_OPEN/VOP_CLOSE on a diskdevice.) > > ioctl(2): directed configuration can do almost anything. > > kldload(2)/kldunload(2): can load/unload GEOm classes. > > The last one is the most tricky one: The crude solution is to always > wait for geom to settle before returning to userland from kldload(2), > but there is no point in waiting for GEOM if you loaded a USB > serial driver and doing so would increase the risk of cascade > failures. > > A further complication is that we should not wait for geom to settle > until after we have dropped Giant again because the geom events > might need to grab giant to do their job. Just a note on this: If you sleep in your waiting function (i.e. call msleep() or cv_wait()), then Giant will be dropped automatically so that you don't need to worry about events needing Giant. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Wed Oct 27 06:24:12 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B92816A4CE for ; Wed, 27 Oct 2004 06:24:12 +0000 (GMT) Received: from web40911.mail.yahoo.com (web40911.mail.yahoo.com [66.218.78.208]) by mx1.FreeBSD.org (Postfix) with SMTP id 1E6BB43D46 for ; Wed, 27 Oct 2004 06:24:12 +0000 (GMT) (envelope-from son_jaya@yahoo.com) Message-ID: <20041027062412.25404.qmail@web40911.mail.yahoo.com> Received: from [202.158.77.194] by web40911.mail.yahoo.com via HTTP; Tue, 26 Oct 2004 23:24:12 PDT Date: Tue, 26 Oct 2004 23:24:12 -0700 (PDT) From: sonjaya To: freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: xeon X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2004 06:24:12 -0000 dear all can i use freebsd for my server ( Xeon 2 G ) , if can where should i read the document , i plant use Freebsd 5.2 release. thx ===== SONJAYA