From owner-freebsd-arch@FreeBSD.ORG Sun Jul 3 00:08:06 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org 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 C3BB916A47E; Sun, 3 Jul 2005 00:08:05 +0000 (GMT) (envelope-from ps@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3774643DFA; Sun, 3 Jul 2005 00:07:59 +0000 (GMT) (envelope-from ps@mu.org) Received: by elvis.mu.org (Postfix, from userid 1000) id 2CB6E5DAC5; Sat, 2 Jul 2005 17:07:45 -0700 (PDT) X-Original-To: ps@mu.org Delivered-To: ps@mu.org Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by elvis.mu.org (Postfix) with ESMTP id 5C40F5C9F5 for ; Fri, 12 Nov 2004 06:59:17 -0800 (PST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id F381456583; Fri, 12 Nov 2004 14:59:15 +0000 (GMT) (envelope-from owner-freebsd-net@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 2F5CD16A4E3; Fri, 12 Nov 2004 14:59:14 +0000 (GMT) Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1C7E16A4CE for ; Fri, 12 Nov 2004 14:59:10 +0000 (GMT) Received: from vampire.homelinux.org (p548082DF.dip.t-dialin.net [84.128.130.223]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8644143D31 for ; Fri, 12 Nov 2004 14:59:09 +0000 (GMT) (envelope-from mlaier@vampire.homelinux.org) Received: (qmail 92219 invoked by uid 1001); 12 Nov 2004 14:58:14 -0000 From: Max Laier To: Ruslan Ermilov Message-ID: <20041112145814.GA92163@router.laiers.local> References: <200411112124.12616.max@love2party.net> <20041112083014.GB41844@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041112083014.GB41844@ip.net.ua> User-Agent: Mutt/1.4.2.1i X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-net@freebsd.org Errors-To: owner-freebsd-net@freebsd.org X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on elvis.mu.org X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.0 X-Spam-Level: Cc: Max Laier , freebsd-arch@freebsd.org, freebsd-net@freebsd.org Subject: Re: in.c autoadding prefix route X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sun, 03 Jul 2005 00:08:06 -0000 X-Original-Date: Fri, 12 Nov 2004 15:58:14 +0100 X-List-Received-Date: Sun, 03 Jul 2005 00:08:06 -0000 On Fri, Nov 12, 2004 at 10:30:14AM +0200, Ruslan Ermilov wrote: > Hi Max, > > On Thu, Nov 11, 2004 at 09:24:05PM +0100, Max Laier wrote: > > I know I have sent this a couple of times before, but never got anywhere. This > > time I am set to commit! > > > Hey, you did it! ;) > > > The attached patch (http://people.freebsd.org/~mlaier/in.c.patch) derived from > > WIDE via OpenBSD in.c, rev 1.21 improves the handling of automatic prefix > > routes. > > > > Right now you can't have two legs into the same network. If you want to, you > > must give on of the interfaces a host address only (netmask /32). This way it > > is not possible to hand over the route if one of the interfaces is > > "removed" (however this is done in the special case). > > > > The patch allows to add more than on IPv4 address with the same prefix. In the > > case that there is a route already, we leave it alone and add the new address > > without the IFA_ROUTE flag. When we remove an address later on, that has a > > route associated, we try to find an alternative address to use for the route > > and hand it over. > > > I cannot give your patch a thorough review at the moment, but I like the > algorithm, and I don't see how it can hurt anything. > > > --- ../dist/sys/netinet/in.c Sat Nov 6 21:01:08 2004 > > +++ sys/netinet/in.c Mon Nov 8 02:05:17 2004 > > @@ -654,14 +684,7 @@ > > register struct ifnet *ifp; > > register struct in_ifaddr *ia; > > { > > - > > - if ((ia->ia_flags & IFA_ROUTE) == 0) > > - return; > > - if (ifp->if_flags & (IFF_LOOPBACK|IFF_POINTOPOINT)) > > - rtinit(&(ia->ia_ifa), (int)RTM_DELETE, RTF_HOST); > > - else > > - rtinit(&(ia->ia_ifa), (int)RTM_DELETE, 0); > > - ia->ia_flags &= ~IFA_ROUTE; > > + in_scrubprefix(ia); > > } > > > Looks like "ifp" argument is no longer needed for in_ifscrub(), > perhaps it should be killed then. As in_ifscrub() isn't static in in.c I think it must be considered kernel API and hence I will wait with this cleanup 'till after the MFC. I otherwise agree that it should be done. > Also, there are a lot of style bugs (besides those that others > have already mentioned), the most annoying is comments -- they > should be written as per style(9) (make them look like the real > sentences). I updated the patch at: http://people.freebsd.org/~mlaier/in.c.patch with new comments. Can you be more specific about the other style(9) violations, as I don't seem to find them. K&R was choosen as the rest of in.c is K&R still and I think style(9) requires that the overall style of a file is maintained. Thanks. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Sun Jul 3 00:08:07 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org 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 4B63F16A471; Sun, 3 Jul 2005 00:08:06 +0000 (GMT) (envelope-from ps@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD74443DE5; Sun, 3 Jul 2005 00:07:52 +0000 (GMT) (envelope-from ps@mu.org) Received: by elvis.mu.org (Postfix, from userid 1000) id 3BD225DB19; Sat, 2 Jul 2005 17:07:44 -0700 (PDT) X-Original-To: ps@mu.org Delivered-To: ps@mu.org Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by elvis.mu.org (Postfix) with ESMTP id 01BB35C99D for ; Tue, 9 Nov 2004 01:27:36 -0800 (PST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 2303E55F04; Tue, 9 Nov 2004 09:27:32 +0000 (GMT) (envelope-from owner-freebsd-net@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 6B8F616A4CE; Tue, 9 Nov 2004 09:27:31 +0000 (GMT) Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AED216A4CE for ; Tue, 9 Nov 2004 09:27:29 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B69E43D54 for ; Tue, 9 Nov 2004 09:27:28 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 35975 invoked from network); 9 Nov 2004 09:22:42 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 9 Nov 2004 09:22:42 -0000 Message-ID: <41908D80.8EAEF656@freebsd.org> From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mallman@icir.org References: <20041109035203.9ED891FB5E2@lawyers.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-net@freebsd.org Errors-To: owner-freebsd-net@freebsd.org X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on elvis.mu.org X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.0 X-Spam-Level: Cc: freebsd-net@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sun, 03 Jul 2005 00:08:08 -0000 X-Original-Date: Tue, 09 Nov 2004 10:27:28 +0100 X-List-Received-Date: Sun, 03 Jul 2005 00:08:08 -0000 Mark Allman wrote: > > (catching up ...) > > > I would rather have Andre work with me to get any other > > rinkles out of SCTP that he deems are there... and get the > > KAME-SCTP stack ported directly in to FreeBSD.. this IMO ... would > > make more sense... Get something that is pretty well baked (IMO at > > least) and work to get it "productionized" (even though I don't > > feel it needs much work in this vein)... > > I do not prefer xor. > > I agree that it'd be nice if SCTP was rolled into freebsd. But, these > things seem orthogonal to me. The author of the BSD SCTP code is working on a direct FreeBSD native port (no KAME detour to take). -- Andre _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Sun Jul 3 00:08:45 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org 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 C608216A423; Sun, 3 Jul 2005 00:08:45 +0000 (GMT) (envelope-from ps@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C1E943D86; Sun, 3 Jul 2005 00:08:00 +0000 (GMT) (envelope-from ps@mu.org) Received: by elvis.mu.org (Postfix, from userid 1000) id 5D7715DB72; Sat, 2 Jul 2005 17:07:45 -0700 (PDT) X-Original-To: ps@mu.org Delivered-To: ps@mu.org Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by elvis.mu.org (Postfix) with ESMTP id 623805C96B for ; Fri, 12 Nov 2004 00:31:11 -0800 (PST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 9572C563B3; Fri, 12 Nov 2004 08:30:56 +0000 (GMT) (envelope-from owner-freebsd-net@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id B186E16A527; Fri, 12 Nov 2004 08:30:48 +0000 (GMT) Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CDF116A4CE; Fri, 12 Nov 2004 08:30:43 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7526043D2D; Fri, 12 Nov 2004 08:30:42 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iAC8Ueho084326; Fri, 12 Nov 2004 10:30:41 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 04757-19; Fri, 12 Nov 2004 10:30:36 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id iAC8UEqs084054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Nov 2004 10:30:14 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id iAC8UE0w051003; Fri, 12 Nov 2004 10:30:14 +0200 (EET) (envelope-from ru) From: Ruslan Ermilov To: Max Laier Message-ID: <20041112083014.GB41844@ip.net.ua> References: <200411112124.12616.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GID0FwUMdk1T2AWN" Content-Disposition: inline In-Reply-To: <200411112124.12616.max@love2party.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-net@freebsd.org Errors-To: owner-freebsd-net@freebsd.org X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on elvis.mu.org X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.0 X-Spam-Level: Cc: freebsd-net@freebsd.org, freebsd-arch@freebsd.org Subject: Re: in.c autoadding prefix route X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sun, 03 Jul 2005 00:08:46 -0000 X-Original-Date: Fri, 12 Nov 2004 10:30:14 +0200 X-List-Received-Date: Sun, 03 Jul 2005 00:08:46 -0000 --GID0FwUMdk1T2AWN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Max, On Thu, Nov 11, 2004 at 09:24:05PM +0100, Max Laier wrote: > I know I have sent this a couple of times before, but never got anywhere.= This=20 > time I am set to commit! >=20 Hey, you did it! ;) > The attached patch (http://people.freebsd.org/~mlaier/in.c.patch) derived= from=20 > WIDE via OpenBSD in.c, rev 1.21 improves the handling of automatic prefix= =20 > routes. >=20 > Right now you can't have two legs into the same network. If you want to, = you=20 > must give on of the interfaces a host address only (netmask /32). This wa= y it=20 > is not possible to hand over the route if one of the interfaces is=20 > "removed" (however this is done in the special case). >=20 > The patch allows to add more than on IPv4 address with the same prefix. I= n the=20 > case that there is a route already, we leave it alone and add the new add= ress=20 > without the IFA_ROUTE flag. When we remove an address later on, that has = a=20 > route associated, we try to find an alternative address to use for the ro= ute=20 > and hand it over. >=20 I cannot give your patch a thorough review at the moment, but I like the algorithm, and I don't see how it can hurt anything. > --- ../dist/sys/netinet/in.c Sat Nov 6 21:01:08 2004 > +++ sys/netinet/in.c Mon Nov 8 02:05:17 2004 > @@ -654,14 +684,7 @@ > register struct ifnet *ifp; > register struct in_ifaddr *ia; > { > - > - if ((ia->ia_flags & IFA_ROUTE) =3D=3D 0) > - return; > - if (ifp->if_flags & (IFF_LOOPBACK|IFF_POINTOPOINT)) > - rtinit(&(ia->ia_ifa), (int)RTM_DELETE, RTF_HOST); > - else > - rtinit(&(ia->ia_ifa), (int)RTM_DELETE, 0); > - ia->ia_flags &=3D ~IFA_ROUTE; > + in_scrubprefix(ia); > } > =20 Looks like "ifp" argument is no longer needed for in_ifscrub(), perhaps it should be killed then. Also, there are a lot of style bugs (besides those that others have already mentioned), the most annoying is comments -- they should be written as per style(9) (make them look like the real sentences). Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --GID0FwUMdk1T2AWN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBlHSWqRfpzJluFF4RAsJbAJ9MrlyCTjeeC7Db9kC5iZ/xBrt8KQCeIdRy 3pYQvaSeF7SeF+iohADcOmM= =4Ken -----END PGP SIGNATURE----- --GID0FwUMdk1T2AWN-- From owner-freebsd-arch@FreeBSD.ORG Sun Jul 3 00:09:32 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org 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 D5FD516A433; Sun, 3 Jul 2005 00:09:31 +0000 (GMT) (envelope-from ps@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6408D43D5C; Sun, 3 Jul 2005 00:08:05 +0000 (GMT) (envelope-from ps@mu.org) Received: by elvis.mu.org (Postfix, from userid 1000) id 01E8B5DB88; Sat, 2 Jul 2005 17:07:45 -0700 (PDT) X-Original-To: ps@mu.org Delivered-To: ps@mu.org Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by elvis.mu.org (Postfix) with ESMTP id 796B65C9BE for ; Thu, 11 Nov 2004 19:15:05 -0800 (PST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id E359556A3E; Fri, 12 Nov 2004 03:13:29 +0000 (GMT) (envelope-from owner-freebsd-net@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 849CD16A52B; Fri, 12 Nov 2004 03:13:20 +0000 (GMT) Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3183A16A4CE; Fri, 12 Nov 2004 03:13:15 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C9A843D1D; Fri, 12 Nov 2004 03:13:15 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id iAC3DJGI004851; Thu, 11 Nov 2004 19:13:19 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id iAC3DIPO004850; Thu, 11 Nov 2004 19:13:18 -0800 From: Brooks Davis To: Max Laier Message-ID: <20041112031318.GC1809@odin.ac.hmc.edu> References: <200411112124.12616.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f0KYrhQ4vYSV2aJu" Content-Disposition: inline In-Reply-To: <200411112124.12616.max@love2party.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-net@freebsd.org Errors-To: owner-freebsd-net@freebsd.org X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on elvis.mu.org X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.0 X-Spam-Level: Cc: freebsd-net@freebsd.org, freebsd-arch@freebsd.org Subject: Re: in.c autoadding prefix route X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sun, 03 Jul 2005 00:09:32 -0000 X-Original-Date: Thu, 11 Nov 2004 19:13:18 -0800 X-List-Received-Date: Sun, 03 Jul 2005 00:09:32 -0000 --f0KYrhQ4vYSV2aJu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 11, 2004 at 09:24:05PM +0100, Max Laier wrote: > All, >=20 > I know I have sent this a couple of times before, but never got anywhere.= This=20 > time I am set to commit! >=20 > The attached patch (http://people.freebsd.org/~mlaier/in.c.patch) derived= from=20 > WIDE via OpenBSD in.c, rev 1.21 improves the handling of automatic prefix= =20 > routes. >=20 > Right now you can't have two legs into the same network. If you want to, = you=20 > must give on of the interfaces a host address only (netmask /32). This wa= y it=20 > is not possible to hand over the route if one of the interfaces is=20 > "removed" (however this is done in the special case). >=20 > The patch allows to add more than on IPv4 address with the same prefix. I= n the=20 > case that there is a route already, we leave it alone and add the new add= ress=20 > without the IFA_ROUTE flag. When we remove an address later on, that has = a=20 > route associated, we try to find an alternative address to use for the ro= ute=20 > and hand it over. >=20 > This is required for CARP, but should be helpful for other situations as = well. I have no objections so this change. Does this help or hurt our quest to be able to usefully bind to 0.0.0.0? It would be really nice if we could eventually do this so we could stop running bpf on 90+% of all machines just so we could use DHCP. -- Brooks --f0KYrhQ4vYSV2aJu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBlCpNXY6L6fI4GtQRAipzAKCdvYyPyE3Sts/yUbdDB+/4PKClMwCgh1Be nuaMa9WAlet2jsCi4/WCx/k= =p6N3 -----END PGP SIGNATURE----- --f0KYrhQ4vYSV2aJu-- From owner-freebsd-arch@FreeBSD.ORG Sun Jul 3 00:37:56 2005 Return-Path: X-Original-To: arch@freebsd.org 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 D3BD116A4E8; Sun, 3 Jul 2005 00:37:41 +0000 (GMT) (envelope-from ps@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A7434449D; Sun, 3 Jul 2005 00:21:21 +0000 (GMT) (envelope-from ps@mu.org) Received: by elvis.mu.org (Postfix, from userid 1000) id 72FC9624AB; Sat, 2 Jul 2005 17:20:07 -0700 (PDT) X-Original-To: ps@mu.org Delivered-To: ps@mu.org Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by elvis.mu.org (Postfix) with ESMTP id A336D5C900 for ; Sun, 27 Feb 2005 11:40:31 -0800 (PST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 1D2CA568F5; Sun, 27 Feb 2005 19:40:24 +0000 (GMT) (envelope-from owner-freebsd-current@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 56B5416A4CE; Sun, 27 Feb 2005 19:40:23 +0000 (GMT) Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4D5C16A4D2; Sun, 27 Feb 2005 19:39:10 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0E6E43D6B; Sun, 27 Feb 2005 19:39:09 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j1RJd8Jr040565; Sun, 27 Feb 2005 20:39:08 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org, current@freebsd.org From: Poul-Henning Kamp Message-ID: <40564.1109533148@critter.freebsd.dk> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on elvis.mu.org X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL, BAYES_00, J_CHICKENPOX_42, J_CHICKENPOX_55 autolearn=no version=3.0.2 X-Spam-Level: Cc: Subject: [REVIEW/TEST] device liberation patches. X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sun, 03 Jul 2005 00:37:56 -0000 X-Original-Date: Sun, 27 Feb 2005 20:39:08 +0100 X-List-Received-Date: Sun, 03 Jul 2005 00:37:56 -0000 This patch decouples entirely the userland and kernel concept of major+minor device number. Userland will see a copy of the devfs inode number and the kernel will see what it always saw. After this patch goes into -current in the middle of march, we can do away with the notion of major device numbers, and remove the 256 limit on number of device drivers and get rid of the stupid hole in the minor number field and finally stand a chance to get the locking of devices (struct cdev) hammered into a sensible format. If anything breaks when running with this patch, a device major/minor is passed through some covert channel between userland to the kernel where it shouldn't be. Such channels very likely implement security risks in relation to jails/chroot, so they should be fixed properly and not just worked around. Poul-Henning Index: fs/devfs/devfs_devs.c =================================================================== RCS file: /home/ncvs/src/sys/fs/devfs/devfs_devs.c,v retrieving revision 1.33 diff -u -r1.33 devfs_devs.c --- fs/devfs/devfs_devs.c 10 Feb 2005 12:22:17 -0000 1.33 +++ fs/devfs/devfs_devs.c 27 Feb 2005 19:16:35 -0000 @@ -424,3 +424,32 @@ if (ino < devfs_nextino) devfs_nextino = ino; } + +/* + * Helper sysctl for devname(3). We're given a struct cdev * and return + * the name, if any, registered by the device driver. + */ +static int +sysctl_devname(SYSCTL_HANDLER_ARGS) +{ + int error; + dev_t ud; + struct cdev *dev, **dp; + + error = SYSCTL_IN(req, &ud, sizeof (ud)); + if (error) + return (error); + if (ud == NODEV) + return(EINVAL); + dp = devfs_itod(ud); + if (dp == NULL) + return(ENOENT); + dev = *dp; + if (dev == NULL) + return(ENOENT); + return(SYSCTL_OUT(req, dev->si_name, strlen(dev->si_name) + 1)); + return (error); +} + +SYSCTL_PROC(_kern, OID_AUTO, devname, CTLTYPE_OPAQUE|CTLFLAG_RW|CTLFLAG_ANYBODY, + NULL, 0, sysctl_devname, "", "devname(3) handler"); Index: fs/devfs/devfs_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/fs/devfs/devfs_vnops.c,v retrieving revision 1.105 diff -u -r1.105 devfs_vnops.c --- fs/devfs/devfs_vnops.c 22 Feb 2005 18:17:31 -0000 1.105 +++ fs/devfs/devfs_vnops.c 27 Feb 2005 19:16:35 -0000 @@ -441,7 +441,7 @@ vap->va_mtime = dev->si_mtime; fix(dev->si_ctime); vap->va_ctime = dev->si_ctime; - vap->va_rdev = dev->si_udev; + vap->va_rdev = de->de_inode; } vap->va_gen = 0; vap->va_flags = 0; Index: kern/kern_conf.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_conf.c,v retrieving revision 1.172 diff -u -r1.172 kern_conf.c --- kern/kern_conf.c 22 Feb 2005 15:51:07 -0000 1.172 +++ kern/kern_conf.c 27 Feb 2005 19:16:35 -0000 @@ -800,30 +800,3 @@ free(cd, M_DEVBUF); *cdp = NULL; } - -/* - * Helper sysctl for devname(3). We're given a struct cdev * and return - * the name, if any, registered by the device driver. - */ -static int -sysctl_devname(SYSCTL_HANDLER_ARGS) -{ - int error; - dev_t ud; - struct cdev *dev; - - error = SYSCTL_IN(req, &ud, sizeof (ud)); - if (error) - return (error); - if (ud == NODEV) - return(EINVAL); - dev = findcdev(ud); - if (dev == NULL) - error = ENOENT; - else - error = SYSCTL_OUT(req, dev->si_name, strlen(dev->si_name) + 1); - return (error); -} - -SYSCTL_PROC(_kern, OID_AUTO, devname, CTLTYPE_OPAQUE|CTLFLAG_RW|CTLFLAG_ANYBODY, - NULL, 0, sysctl_devname, "", "devname(3) handler"); -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ 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" From owner-freebsd-arch@FreeBSD.ORG Sun Jul 3 01:02:47 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org 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 5A14016B554; Sun, 3 Jul 2005 01:02:06 +0000 (GMT) (envelope-from ps@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6E4144BAF; Sun, 3 Jul 2005 00:52:32 +0000 (GMT) (envelope-from ps@mu.org) Received: by elvis.mu.org (Postfix, from userid 1000) id 002825DAC0; Sat, 2 Jul 2005 17:07:33 -0700 (PDT) X-Original-To: ps@mu.org Delivered-To: ps@mu.org Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by elvis.mu.org (Postfix) with ESMTP id BDDC65C9A0 for ; Fri, 22 Oct 2004 08:23:31 -0700 (PDT) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 3BB4F56F2A; Fri, 22 Oct 2004 15:23:14 +0000 (GMT) (envelope-from owner-freebsd-net@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 2C06516A4F2; Fri, 22 Oct 2004 15:23:09 +0000 (GMT) Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89F9E16A4D2 for ; Fri, 22 Oct 2004 15:23:06 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9FA243D49 for ; Fri, 22 Oct 2004 15:23:05 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 87400 invoked from network); 22 Oct 2004 15:21:31 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 22 Oct 2004 15:21:31 -0000 Message-ID: <417925D8.C426261E@freebsd.org> From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= References: <4177C8AD.6060706@freebsd.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-net@freebsd.org Errors-To: owner-freebsd-net@freebsd.org X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on elvis.mu.org X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.0 X-Spam-Level: X-Mailman-Approved-At: Sun, 03 Jul 2005 11:43:52 +0000 Cc: freebsd-net@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sun, 03 Jul 2005 01:02:47 -0000 X-Original-Date: Fri, 22 Oct 2004 17:23:04 +0200 X-List-Received-Date: Sun, 03 Jul 2005 01:02:47 -0000 Dag-Erling Smørgrav wrote: > > Andre Oppermann writes: > > o T/TCP only available on FreeBSD. No other Operating System or TCP/IP > > stack implements it to my knowledge. Certainly no OS that is common. > > AFAIK, both Linux and Windows support it, at least on the server side > (i.e. they can receive T/TCP connections even if they can't initiate > them). Any fully TCP compliant stack should be able to accept T/TCP connection attempts. However if it didn't implement T/TCP itself it would simply do the standard 3WSH. So yes, you can use T/TCP from the client side towards any TCP server but you don't get any benefit from it. Neither Windows or Linux implement it. Windows during the NT4 days had a bug in the TCP stack that allowed something like T/TCP but it wasn't T/TCP and didn't work with T/TCP compliant clients. > > o T/TCP requires different API calls than TCP to use it (UDP like). > > Only on the client side, I believe. Yes, on the client side. sendto() instead of connect()+write(). > > o T/TCP is not supported by any common network application. > > Prior to libfetch, fetch(1) used it by default. Only if T/TCP was enabled on the machine (net.inet.tcp.rfc1644). > > Thus after the removal of T/TCP for the reasons above I want to provide > > a work-alike replacement for T/TCP's functionality: > > Unlike your proposal, T/TCP is described in Internet RFCs (1379 and > 1644) and well-known by the Internet community. Well known for its gaping security holes and left unimplemented on any other OS except FreeBSD. -- Andre _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Sun Jul 3 01:02:42 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org 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 CABE616B545; Sun, 3 Jul 2005 01:02:05 +0000 (GMT) (envelope-from ps@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD27C44BE7; Sun, 3 Jul 2005 00:52:39 +0000 (GMT) (envelope-from ps@mu.org) Received: by elvis.mu.org (Postfix, from userid 1000) id 06AFC5DFA1; Sat, 2 Jul 2005 17:08:28 -0700 (PDT) X-Original-To: ps@mu.org Delivered-To: ps@mu.org Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by elvis.mu.org (Postfix) with ESMTP id F3E7D5CA41 for ; Fri, 13 May 2005 09:45:32 -0700 (PDT) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id E4F7A5567F for ; Fri, 13 May 2005 16:45:32 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: by hub.freebsd.org (Postfix) id DEFB016A4D0; Fri, 13 May 2005 16:45:32 +0000 (GMT) Delivered-To: ps@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB62516A4CE; Fri, 13 May 2005 16:45:32 +0000 (GMT) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 786B243D77; Fri, 13 May 2005 16:45:32 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j4DGjU1Q015343; Fri, 13 May 2005 12:45:31 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4284D4BC.9070705@FreeBSD.org> References: <200410020349.i923nG8v021675@northstar.hetzel.org> <20041002052856.GE17792@nexus.dglawrence.com> <20041002233542.GL714@nexus.dglawrence.com> <421DAD8F.6000704@portaone.com> <4284D038.50805@FreeBSD.org> <4284D4BC.9070705@FreeBSD.org> To: Maxim Sobolev From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on elvis.mu.org X-Spam-Status: No, score=-4.2 required=5.0 tests=AWL, BAYES_00, CN_SUBJECT_799, SARE_HEAD_HDR_XCANITP autolearn=no version=3.0.2 X-Spam-Level: X-Mailman-Approved-At: Sun, 03 Jul 2005 11:44:18 +0000 Cc: Paul Saab , freebsd-arch@FreeBSD.org Subject: Re: Bug in #! processing - One More Time X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sun, 03 Jul 2005 01:02:43 -0000 X-Original-Date: Fri, 13 May 2005 12:45:29 -0400 X-List-Received-Date: Sun, 03 Jul 2005 01:02:43 -0000 At 7:24 PM +0300 5/13/05, Maxim Sobolev wrote: >Garance A Drosihn wrote: >>At 7:05 PM +0300 5/13/05, Maxim Sobolev wrote: >> >>>Attached please find patch which rips any special processing of >>>command line arguments. It should put FreeBSD into the very same >>>ship with the rest of unices and linuces out there. >> >>Actually, thanks to a message from Paul Saab last weekend, I've >>been working on this change for much of the past week. > >Well, let's agree that if I don't hear from you for another 2 days >I'll commit my change, OK? I should have done enough testing by Sunday evening to say something, one way or another. Sure. Note that I'm not just "running this through buildworld". That's how all the previous changes were tested, too. I have a whole battery of tests that I've been slogging through. And most the time I've been doing that, I've been muttering to myself "How did I talk myself into this?"... -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Sun Jul 3 01:02:46 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org 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 5872E16B553; Sun, 3 Jul 2005 01:02:06 +0000 (GMT) (envelope-from ps@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id D617644B99; Sun, 3 Jul 2005 00:52:32 +0000 (GMT) (envelope-from ps@mu.org) Received: by elvis.mu.org (Postfix, from userid 1000) id 09EC05DAA9; Sat, 2 Jul 2005 17:07:33 -0700 (PDT) X-Original-To: ps@mu.org Delivered-To: ps@mu.org Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by elvis.mu.org (Postfix) with ESMTP id 0B46D5C8E3 for ; Sat, 23 Oct 2004 06:24:22 -0700 (PDT) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id DABCC560B4; Sat, 23 Oct 2004 13:24:18 +0000 (GMT) (envelope-from owner-freebsd-net@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 3478316A4D0; Sat, 23 Oct 2004 13:24:18 +0000 (GMT) Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17B8316A4CE; Sat, 23 Oct 2004 13:24:12 +0000 (GMT) Received: from stewart.chicago.il.us (dpc674425142.direcpc.com [67.44.25.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A73843D69; Sat, 23 Oct 2004 13:24:09 +0000 (GMT) (envelope-from randall@stewart.chicago.il.us) Received: from stewart.chicago.il.us (localhost [127.0.0.1]) i9NDO3tr031523; Sat, 23 Oct 2004 09:24:06 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <417A5B28.9080308@stewart.chicago.il.us> 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: mallman@icir.org References: <20041021183238.00E8977A9D0@guns.icir.org> In-Reply-To: <20041021183238.00E8977A9D0@guns.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-net@freebsd.org Errors-To: owner-freebsd-net@freebsd.org X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on elvis.mu.org X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.0 X-Spam-Level: X-Mailman-Approved-At: Sun, 03 Jul 2005 11:44:45 +0000 Cc: freebsd-net@freebsd.org, Andre Oppermann , freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sun, 03 Jul 2005 01:02:46 -0000 X-Original-Date: Sat, 23 Oct 2004 09:22:48 -0400 X-List-Received-Date: Sun, 03 Jul 2005 01:02:46 -0000 Mark Allman wrote: >>Sure. To make you sleep better it will be disabled by default (like >>T/TCP) and possibly even not compliled in by default (#ifdef'd). > > > Part of your argument against T/TCP. :-) > > >>A writeup will follow once I get there. I made this request before I >>start working on it to prevent to waste my time on it if people wanted >>to religiously stick to T/TCP. > > > I think moving on from T/TCP is fine, don't get me wrong. And, I am all > for seeing new schemes that buy us some of the things T/TCP was designed > for. I am just not enthusiastic about dumping things into the kernel > without some review and thought (by more than one person; and, that is > not a knock on you --- if I had a nickel for every half-baked thing I'd > implemented somewhere .... basically, it's good to get different > perspectives). > > Doing this in a systematic way may have benefits beyond FreeBSD, as > well, of course. I would rather have Andre work with me to get any other rinkles out of SCTP that he deems are there... and get the KAME-SCTP stack ported directly in to FreeBSD.. this IMO ... would make more sense... Get something that is pretty well baked (IMO at least) and work to get it "productionized" (even though I don't feel it needs much work in this vein)... R > > allman > > > -- Randall Stewart 803-345-0369 815-342-5222(cell) _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Sun Jul 3 01:03:52 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org 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 DE67616B082; Sun, 3 Jul 2005 01:02:55 +0000 (GMT) (envelope-from ps@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7598944D21; Sun, 3 Jul 2005 00:54:57 +0000 (GMT) (envelope-from ps@mu.org) Received: by elvis.mu.org (Postfix, from userid 1000) id 180665DF8E; Sat, 2 Jul 2005 17:08:28 -0700 (PDT) X-Original-To: ps@mu.org Delivered-To: ps@mu.org Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by elvis.mu.org (Postfix) with ESMTP id 6F8295CA74 for ; Fri, 13 May 2005 09:24:39 -0700 (PDT) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 61A1B55A2A for ; Fri, 13 May 2005 16:24:39 +0000 (GMT) (envelope-from sobomax@FreeBSD.org) Received: by hub.freebsd.org (Postfix) id 5CF6C16A4D0; Fri, 13 May 2005 16:24:39 +0000 (GMT) Delivered-To: ps@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5992416A4CE; Fri, 13 May 2005 16:24:39 +0000 (GMT) Received: from www.portaone.com (support.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9784443D31; Fri, 13 May 2005 16:24:38 +0000 (GMT) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.4.107] (039sub211.uottawa.ca [137.122.39.144]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id j4DGOZFk037806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 May 2005 18:24:36 +0200 (CEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <4284D4BC.9070705@FreeBSD.org> From: Maxim Sobolev User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Garance A Drosihn References: <200410020349.i923nG8v021675@northstar.hetzel.org> <20041002052856.GE17792@nexus.dglawrence.com> <20041002233542.GL714@nexus.dglawrence.com> <421DAD8F.6000704@portaone.com> <4284D038.50805@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/876/Fri May 13 01:14:29 2005 on www.portaone.com X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on elvis.mu.org X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,CN_SUBJECT_799 autolearn=no version=3.0.2 X-Spam-Level: X-Mailman-Approved-At: Sun, 03 Jul 2005 11:45:09 +0000 Cc: Paul Saab , freebsd-arch@FreeBSD.org Subject: Re: Bug in #! processing - One More Time X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sun, 03 Jul 2005 01:03:52 -0000 X-Original-Date: Fri, 13 May 2005 19:24:28 +0300 X-List-Received-Date: Sun, 03 Jul 2005 01:03:52 -0000 Garance A Drosihn wrote: > At 7:05 PM +0300 5/13/05, Maxim Sobolev wrote: > >> Attached please find patch which rips any special processing of >> command line arguments. It should put FreeBSD into the very same >> ship with the rest of unices and linuces out there. > > > Actually, thanks to a message from Paul Saab last weekend, I've > been working on this change for much of the past week. I want to > make sure that this time we get the change right. As near as I > can tell, every single change which has been made to this file in > the past year has been wrong in one way or another, so I've been > extra-paranoid that I understand what is going on and why it's > going on... Well, let's agree that if I don't hear from you for another 2 days I'll commit my change, OK? -Maxim From owner-freebsd-arch@FreeBSD.ORG Sun Jul 3 18:19:21 2005 Return-Path: X-Original-To: arch@freebsd.org 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 9906B16A41C for ; Sun, 3 Jul 2005 18:19:21 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3466643D48 for ; Sun, 3 Jul 2005 18:19:21 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: by zproxy.gmail.com with SMTP id 8so306768nzo for ; Sun, 03 Jul 2005 11:19:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=K9l/rwSvjrNLrnvHHf7oy3arnkLWd6r9+sKWzNAwIj3P8sXKvZsZkdRT5GjBEwmcTg+GDo8GNU2vhzh1Qua42GTAeQEU+fPXw+Hdc7q5FMp0apukDyqj5TfQmKV1cgcBptAsk7MLeZVNZ+Cz2MNlVui5Xe/ZbSwwl5kJXPxKO7I= Received: by 10.36.222.33 with SMTP id u33mr1257905nzg; Sun, 03 Jul 2005 11:19:20 -0700 (PDT) Received: by 10.36.68.15 with HTTP; Sun, 3 Jul 2005 11:19:20 -0700 (PDT) Message-ID: <34cb7c84050703111925c558e4@mail.gmail.com> Date: Sun, 3 Jul 2005 19:19:20 +0100 From: Peter Edwards To: arch@freebsd.org In-Reply-To: <20050701144021.GA2428@stack.nl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_8670_3441211.1120414760756" References: <20050701132104.GA95135@freefall.freebsd.org> <20050701144021.GA2428@stack.nl> X-Mailman-Approved-At: Mon, 04 Jul 2005 12:50:00 +0000 Cc: Peter Edwards , Marc Olzheim Subject: Re: ktrace and KTR_DROP X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Peter Edwards List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2005 18:19:21 -0000 ------=_Part_8670_3441211.1120414760756 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > login: panic: ktrace: no trace vnode > cpuid =3D 1 > KDB: stack backtrace: > kdb_backtrace(100,c6c0b000,c65e08d4,c5d4ae80,c6c0b000) at 0xc053efa9 =3D = kdb_backtrace+0x29 > panic(c06bec25,8,2,c717e180,ec519cd8) at 0xc0529174 =3D panic+0x114 > ktr_getrequest(1,0,c6c0b000,c65e08d4,ec519d30) at 0xc051aa7b =3D ktr_getr= equest+0xf3 > ktrsyscall(bd,2,ec519d04) at 0xc051ad7f =3D ktrsyscall+0x3b > syscall(2f,2f,2f,280ee000,0) at 0xc0680329 =3D syscall+0x155 > Xint0x80_syscall() at 0xc066fcff =3D Xint0x80_syscall+0x1f > --- syscall (189, FreeBSD ELF32, fstat), eip =3D 0x280cea23, esp =3D 0xbf= bfe9f0, ebp =3D 0xbfbfea8c --- > boot() called on cpu#0 > Uptime: 17m39s > Dumping 3967 MB > 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 32= 0 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 6= 24 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 = 928 944 960 976 992 1008 1024 1040 1056 1072 1088 1104 1120 1136 1152 1168 = 1184 1200 1216 ... This pointed out at least one fault in the patch: the conditions tested by KTRCHECK() can be changed after dropping the lock in cv_wait(). More testing to come, but this version is an improvement. ------=_Part_8670_3441211.1120414760756 Content-Type: text/plain; name="kern_ktrace.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="kern_ktrace.txt" SW5kZXg6IGtlcm4va2Vybl9rdHJhY2UuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvdXNyL2N2cy9G cmVlQlNELUNWUy9zcmMvc3lzL2tlcm4va2Vybl9rdHJhY2UuYyx2CnJldHJpZXZpbmcgcmV2aXNp b24gMS4xMDEKZGlmZiAtdSAtcjEuMTAxIGtlcm5fa3RyYWNlLmMKLS0tIGtlcm4va2Vybl9rdHJh Y2UuYwkyNCBKdW4gMjAwNSAxMjowNToyNCAtMDAwMAkxLjEwMQorKysga2Vybi9rZXJuX2t0cmFj ZS5jCTMgSnVsIDIwMDUgMTg6MTY6MjQgLTAwMDAKQEAgLTEwMCw5ICsxMDAsMTUgQEAKIFNZU0NU TF9VSU5UKF9rZXJuX2t0cmFjZSwgT0lEX0FVVE8sIGdlbmlvX3NpemUsIENUTEZMQUdfUlcsICZr dHJfZ2VuaW9zaXplLAogICAgIDAsICJNYXhpbXVtIHNpemUgb2YgZ2VuaW8gZXZlbnQgcGF5bG9h ZCIpOwogCitzdGF0aWMgaW50IGt0cl9uZXZlcmRyb3AgPSAwOworU1lTQ1RMX1VJTlQoX2tlcm5f a3RyYWNlLCBPSURfQVVUTywgbmV2ZXJkcm9wLCBDVExGTEFHX1JXLCAma3RyX25ldmVyZHJvcCwK KyAgICAwLCAiV2FpdCBmb3IgZnJlZSByZXNvdXJjZXMgcmF0aGVyIHRoYW4gZHJvcHBpbmcgZXZl bnRzICIpOworCiBzdGF0aWMgaW50IHByaW50X21lc3NhZ2UgPSAxOwogc3RydWN0IG10eCBrdHJh Y2VfbXR4Owotc3RhdGljIHN0cnVjdCBjdiBrdHJhY2VfY3Y7CitzdGF0aWMgc3RydWN0IGN2IGt0 cmFjZV90b2RvX2N2OyAvKiBzZXJ2aWNlIHRocmVhZCB3YWl0aW5nIGZvciB3b3JrICovCitzdGF0 aWMgc3RydWN0IGN2IGt0cmFjZV9mcmVlcV9jdjsgLyogdGhyZWFkcyB3YWl0aW5nIGZvciBmcmVl IHJlcXVlc3RzICovCitzdGF0aWMgaW50IGt0cmFjZV9mcmVlX3dhaXRlcnMgPSAwOyAvKiBOby4g b2YgdGhyZWFkcyB3YWl0aW5nIG9uIGZyZWVxX2N2ICovCiAKIHN0YXRpYyB2b2lkIGt0cmFjZV9p bml0KHZvaWQgKmR1bW15KTsKIHN0YXRpYyBpbnQgc3lzY3RsX2tlcm5fa3RyYWNlX3JlcXVlc3Rf cG9vbChTWVNDVExfSEFORExFUl9BUkdTKTsKQEAgLTEyMyw3ICsxMjksOCBAQAogCWludCBpOwog CiAJbXR4X2luaXQoJmt0cmFjZV9tdHgsICJrdHJhY2UiLCBOVUxMLCBNVFhfREVGIHwgTVRYX1FV SUVUKTsKLQljdl9pbml0KCZrdHJhY2VfY3YsICJrdHJhY2UiKTsKKwljdl9pbml0KCZrdHJhY2Vf dG9kb19jdiwgImt0cmFjZS50b2RvIik7CisJY3ZfaW5pdCgma3RyYWNlX2ZyZWVxX2N2LCAia3Ry YWNlLmZyZWVxIik7CiAJU1RBSUxRX0lOSVQoJmt0cl90b2RvKTsKIAlTVEFJTFFfSU5JVCgma3Ry X2ZyZWUpOwogCWZvciAoaSA9IDA7IGkgPCBrdHJfcmVxdWVzdHBvb2w7IGkrKykgewpAQCAtMjAw LDYgKzIwNyw4IEBACiAJCQkgICAgTV9XQUlUT0spOwogCQkJbXR4X2xvY2soJmt0cmFjZV9tdHgp OwogCQkJU1RBSUxRX0lOU0VSVF9IRUFEKCZrdHJfZnJlZSwgcmVxLCBrdHJfbGlzdCk7CisJCQlp ZiAoa3RyYWNlX2ZyZWVfd2FpdGVycykKKwkJCQljdl9zaWduYWwoJmt0cmFjZV9mcmVlcV9jdik7 CiAJCQlrdHJfcmVxdWVzdHBvb2wrKzsKIAkJfQogCXJldHVybiAoa3RyX3JlcXVlc3Rwb29sKTsK QEAgLTIxNSwxMiArMjI0LDIxIEBACiAKIAl0ZC0+dGRfcGZsYWdzIHw9IFREUF9JTktUUkFDRTsK IAltdHhfbG9jaygma3RyYWNlX210eCk7CisJZm9yICg7OykgeworCQlyZXEgPSBTVEFJTFFfRklS U1QoJmt0cl9mcmVlKTsKKwkJaWYgKHJlcSAhPSAwIHx8IGt0cl9uZXZlcmRyb3AgPT0gMCkKKwkJ CWJyZWFrOworCQlrdHJhY2VfZnJlZV93YWl0ZXJzKys7CisJCWN2X3dhaXQoJmt0cmFjZV9mcmVl cV9jdiwgJmt0cmFjZV9tdHgpOworCQlrdHJhY2VfZnJlZV93YWl0ZXJzLS07CisJfQorCiAJaWYg KCFLVFJDSEVDSyh0ZCwgdHlwZSkpIHsKIAkJbXR4X3VubG9jaygma3RyYWNlX210eCk7CiAJCXRk LT50ZF9wZmxhZ3MgJj0gflREUF9JTktUUkFDRTsKIAkJcmV0dXJuIChOVUxMKTsKIAl9Ci0JcmVx ID0gU1RBSUxRX0ZJUlNUKCZrdHJfZnJlZSk7CisKIAlpZiAocmVxICE9IE5VTEwpIHsKIAkJU1RB SUxRX1JFTU9WRV9IRUFEKCZrdHJfZnJlZSwga3RyX2xpc3QpOwogCQlyZXEtPmt0cl9oZWFkZXIu a3RyX3R5cGUgPSB0eXBlOwpAQCAtMjU3LDcgKzI3NSw3IEBACiAKIAltdHhfbG9jaygma3RyYWNl X210eCk7CiAJU1RBSUxRX0lOU0VSVF9UQUlMKCZrdHJfdG9kbywgcmVxLCBrdHJfbGlzdCk7Ci0J Y3Zfc2lnbmFsKCZrdHJhY2VfY3YpOworCWN2X3NpZ25hbCgma3RyYWNlX3RvZG9fY3YpOwogCW10 eF91bmxvY2soJmt0cmFjZV9tdHgpOwogCWN1cnRocmVhZC0+dGRfcGZsYWdzICY9IH5URFBfSU5L VFJBQ0U7CiB9CkBAIC0yNzYsNiArMjk0LDggQEAKIAkJZnJlZShyZXEtPmt0cl9oZWFkZXIua3Ry X2J1ZmZlciwgTV9LVFJBQ0UpOwogCW10eF9sb2NrKCZrdHJhY2VfbXR4KTsKIAlTVEFJTFFfSU5T RVJUX0hFQUQoJmt0cl9mcmVlLCByZXEsIGt0cl9saXN0KTsKKwlpZiAoa3RyYWNlX2ZyZWVfd2Fp dGVycykKKwkJY3Zfc2lnbmFsKCZrdHJhY2VfZnJlZXFfY3YpOwogCW10eF91bmxvY2soJmt0cmFj ZV9tdHgpOwogfQogCkBAIC0yOTIsNyArMzEyLDcgQEAKIAlmb3IgKDs7KSB7CiAJCW10eF9sb2Nr KCZrdHJhY2VfbXR4KTsKIAkJd2hpbGUgKFNUQUlMUV9FTVBUWSgma3RyX3RvZG8pKQotCQkJY3Zf d2FpdCgma3RyYWNlX2N2LCAma3RyYWNlX210eCk7CisJCQljdl93YWl0KCZrdHJhY2VfdG9kb19j diwgJmt0cmFjZV9tdHgpOwogCQlyZXEgPSBTVEFJTFFfRklSU1QoJmt0cl90b2RvKTsKIAkJU1RB SUxRX1JFTU9WRV9IRUFEKCZrdHJfdG9kbywga3RyX2xpc3QpOwogCQlLQVNTRVJUKHJlcSAhPSBO VUxMLCAoImdvdCBhIE5VTEwgcmVxdWVzdCIpKTsK ------=_Part_8670_3441211.1120414760756-- From owner-freebsd-arch@FreeBSD.ORG Sun Jul 3 19:54:08 2005 Return-Path: X-Original-To: arch@freebsd.org 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 9E65016A41C for ; Sun, 3 Jul 2005 19:54:08 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F83A43D48 for ; Sun, 3 Jul 2005 19:54:08 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: by zproxy.gmail.com with SMTP id 8so310781nzo for ; Sun, 03 Jul 2005 12:54:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EWgJa4LXLXxWQfrIBalvZvRQ8Bc3S6yVmSZI4vL7we7zyI5ewPsQcbxjiwvuMMumW4Zds6CvcIQTfGQsJjuZ1ZEgy6q5KitjcmHNCjf/YBncWfge0LVLzfsamJAI76+fcfj3LBxAZSk7Y0/rZZJPxi2tdi4OQVopI76tjO3crZk= Received: by 10.36.65.7 with SMTP id n7mr469268nza; Sun, 03 Jul 2005 11:13:32 -0700 (PDT) Received: by 10.36.68.15 with HTTP; Sun, 3 Jul 2005 11:13:32 -0700 (PDT) Message-ID: <34cb7c8405070311131cd1ca8a@mail.gmail.com> Date: Sun, 3 Jul 2005 19:13:32 +0100 From: Peter Edwards To: Robert Watson In-Reply-To: <20050701155757.A36905@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050701132104.GA95135@freefall.freebsd.org> <20050701155757.A36905@fledge.watson.org> X-Mailman-Approved-At: Mon, 04 Jul 2005 12:50:00 +0000 Cc: Peter Edwards , arch@freebsd.org Subject: Re: ktrace and KTR_DROP X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Peter Edwards List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2005 19:54:08 -0000 On 7/1/05, Robert Watson wrote: >=20 > There are two benefits to the current ktrace dispatch model: >=20 > (1) Avoiding untimely sleeping in the execution paths of threads that are > being traced. >=20 > (2) Allowing the traced thread to run ahead asynchronously, hopefully > impacting performance less. >=20 Agreed, as long as the rate it needs to trace at doesn't exceed the rate th= e trace can be recorded at: otherwise, it needs to be flow controlled, either= by calling vn_write, or by waiting for another thread to do so. Just to re-ite= rate, I understand that not slowing down the target process is probably beneficia= l in some circumstances, but you can only do that by loosing trace information, = and in the vast majority of cases that's exactly what you don't want. > One of the things I've been thinking for a few years is that I think I > actually preferred the old model better, there processes (now threads) > would hang a "current record" off of their process (now thread) structure= , > and fill it in as they went along. The upsides of this have to do with > the downsides of the current model: that you don't allow fully > asynchronous execition of the threads with respect to queueing the record= s > to disk, so you don't run into "drop" scenarios, instead slowing down the > process. Likewise, the downsides. >=20 > In the audit code, we pull from a common record queue, but we allocate th= e > record when the system call starts for each process -- if there aren't > records available (or various other reliability-related conditions fail, > such as adequate disk space), we stall the thread entering the kernel > until we can satisfy its record allocation requirements. I don't follow: looking at the code from RELENG_4, it looks pretty similar = to what's there already: create a requst, call ktrwrite, free request. By add= ing the flow control with the patch, you just end up waiting for the free queue= to be non-empty, rather than waiting to aquire the vnode lock and do the write= . Am I missing something? Do I need to go back further in time? >=20 > There are two cases where I really run into problems with the current > model: >=20 > (1) When I'm interacting with a slow file system, such as NFS over > 100mbps, I will always lose records, because it doesn't take long fo= r > the process to get quite ahead of the write-behind. It doesn't even need NFS: syscall throughput is much better than I/O throughput :-) >=20 > (2) When I trace more than one process at a time, the volume of records > overwhelms the write-behind. As long as you need to do physical writes for the syscalls, I don't know how you'l ever avoid that... >=20 > Write coalescing/etc is already provided "for free" by pushing the writes > down into the file system, so other than slowing down the traced process = a > little, I think we don't lose much by moving back to this model. And if > we pre-commit the record storage on system call entry (with the exception > of paths, which generally require potential sleeps anyway), we probably > won't hurt performance all that much, and avoid sleeping in bad places. I'm not sure I follow: are you saying you'd rather move the ktrace resource aquisition out of where the sleep will be more critical? I don't see how you can avoid having the ktrace'd thread wait for as long as it takes for the writer thread to catch up with the system to some point From owner-freebsd-arch@FreeBSD.ORG Mon Jul 4 23:14:02 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org 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 5325716A41C for ; Mon, 4 Jul 2005 23:14:02 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from mailserver.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0D6643D46 for ; Mon, 4 Jul 2005 23:14:01 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by mailserver.sandvine.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 4 Jul 2005 19:14:00 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id 3D2B613643; Mon, 4 Jul 2005 19:14:00 -0400 (EDT) Date: Mon, 4 Jul 2005 19:14:00 -0400 From: Ed Maste To: Peter Wemm Message-ID: <20050704231359.GA58430@sandvine.com> References: <20050623102024.GA89874@frontfree.net> <200506231815.44052.peter@wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200506231815.44052.peter@wemm.org> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 04 Jul 2005 23:14:00.0493 (UTC) FILETIME=[0FC2E5D0:01C580EE] Cc: freebsd-arch@freebsd.org Subject: Re: How to get stack from every thread when doing crash dump? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2005 23:14:02 -0000 On Thu, Jun 23, 2005 at 06:15:43PM -0700, Peter Wemm wrote: > But I wonder if what you're running into is possibly a result of gdb not > parsing the stack frames from exception.s? We do not emit any dwarf2 > call frame information for any assembler code, and gdb6 is dwarf2 > based. And since it is dwarf2 based, during the last cleanups the gdb > developers did, they removed (or moved) the places that we used to > insert stack frame sniffers to cope with crossing the nonstandard > assembler stack frames. As a result, we don't generally show traces > that cross exceptions any more. It seems worse than that -- the gdb backtrace might show unknown or completely bogus frames as a result. For example, we've run across the tty locking issue (discussed on -stable), and backtraces often look like: #6 0xa0723d8a in calltrap () at /usr/src/sys/i386/i386/exception.s:202 #7 0xc7f10018 in ?? () #8 0xa05b0010 in power_profile_set_state (state=0) at /usr/src/sys/kern/subr_power.c:110 #9 0xa05c942c in ttwakeup (tp=0xa23fdc00) at /usr/src/sys/kern/tty.c:2370 #10 0xa05c7d71 in ttymodem (tp=0xa23fdc00, flag=0) at /usr/src/sys/kern/tty.c:1625 when in reality frames 7 and 8 should actually be a single frame in knote(). > If that is the problem you're seeing, then the fix is that somebody > needs to annotate the *.s and *.S files with .cfa_* pseudo-ops so that > dwarf2 frame descriptors are emitted for a -g kernel. This is > non-trivial though. I assume you meant .cfi_* -- .cfi_startproc, .cfi_offset etc? I had a quick look and it doesn't seem like it should be difficult. I ran into one issue though -- these get written to the .eh_frame section. The data emitted by gcc goes in .debug_frame, but the two have the same format. I tried changing the linker script to put both in the .debug_frame section, but ld faild ("Not enough room for program headers"). The .eh_frame section is marked loadable, so it seems ld still tries to create a phdr entry for it. Once I can figure out how to address that I'll test out adding the .cfi_ pseudo-ops to exception.s. -- Ed Maste, Sandvine Incorporated From owner-freebsd-arch@FreeBSD.ORG Mon Jul 4 17:02:40 2005 Return-Path: X-Original-To: arch@freebsd.org 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 47D1B16A41C; Mon, 4 Jul 2005 17:02:40 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 125D443D45; Mon, 4 Jul 2005 17:02:39 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j64H2dvd088731; Mon, 4 Jul 2005 12:02:39 -0500 (CDT) (envelope-from dan) Date: Mon, 4 Jul 2005 12:02:39 -0500 From: Dan Nelson To: Peter Edwards Message-ID: <20050704170239.GQ2392@dan.emsphone.com> References: <20050701132104.GA95135@freefall.freebsd.org> <20050701155757.A36905@fledge.watson.org> <34cb7c8405070311131cd1ca8a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34cb7c8405070311131cd1ca8a@mail.gmail.com> X-OS: FreeBSD 5.4-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.9i X-Mailman-Approved-At: Tue, 05 Jul 2005 12:35:15 +0000 Cc: Peter Edwards , arch@freebsd.org, Robert Watson Subject: Re: ktrace and KTR_DROP X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2005 17:02:40 -0000 In the last episode (Jul 03), Peter Edwards said: > On 7/1/05, Robert Watson wrote: > > There are two cases where I really run into problems with the > > current model: > > > > (1) When I'm interacting with a slow file system, such as NFS over > > 100mbps, I will always lose records, because it doesn't take > > long for the process to get quite ahead of the write-behind. > > It doesn't even need NFS: syscall throughput is much better than I/O > throughput :-) BTW, I often see dropped records even when tracing to md-backed /tmp. Raising kern.ktrace.request_pool from 100 to 1000 helps but does not eliminate drops. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-arch@FreeBSD.ORG Tue Jul 5 00:21:11 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org 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 A775A16A41C for ; Tue, 5 Jul 2005 00:21:11 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 685EC43D45 for ; Tue, 5 Jul 2005 00:21:11 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j650L94W010232; Mon, 4 Jul 2005 17:21:10 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <20050704231359.GA58430@sandvine.com> References: <20050623102024.GA89874@frontfree.net> <200506231815.44052.peter@wemm.org> <20050704231359.GA58430@sandvine.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0674fbcfaecb08e9ffb3a39eaa9cf3d2@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Mon, 4 Jul 2005 17:21:10 -0700 To: Ed Maste X-Mailer: Apple Mail (2.622) X-Mailman-Approved-At: Tue, 05 Jul 2005 12:35:15 +0000 Cc: freebsd-arch@freebsd.org Subject: Re: How to get stack from every thread when doing crash dump? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2005 00:21:11 -0000 On Jul 4, 2005, at 4:14 PM, Ed Maste wrote: > I tried changing the linker script to put both in the .debug_frame > section, but ld faild ("Not enough room for program headers"). The > .eh_frame section is marked loadable, so it seems ld still tries to > create a phdr entry for it. Once I can figure out how to address > that I'll test out adding the .cfi_ pseudo-ops to exception.s. This will not resolve the problem. The problem relates to how signal frames need to be handled in userland code. In order to unwind across traps and signal frames, the debugger needs to know 2 things: which functions are for kernel entry (or signal trampoline) and how to get to the saved registers. Only the first can possibly be addressed by unwind information. One still need to teach the debugger about the trapframes (or signal frames) themselves. I'm working on the import of GDB 6.3, which allows us to handle this case by registering special frame unwinders. Adding .cfi directives is probably a good idea, but it needs a bit more work to fix backtraces. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-arch@FreeBSD.ORG Fri Jul 8 21:51:39 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org 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 2E35916A41C; Fri, 8 Jul 2005 21:51:39 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B513943D48; Fri, 8 Jul 2005 21:51:38 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j68Lvf9C039857; Fri, 8 Jul 2005 15:57:43 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42CEF564.3060503@samsco.org> Date: Fri, 08 Jul 2005 15:51:32 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wilkinson, Alex" References: <1e89cd51050616062241e9e201@mail.gmail.com> <200506222323.26666.peter@wemm.org> <20050623074453.GA71779@squash.dsto.defence.gov.au> In-Reply-To: <20050623074453.GA71779@squash.dsto.defence.gov.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org X-Mailman-Approved-At: Sat, 09 Jul 2005 10:32:57 +0000 Cc: arch@freebsd.org, Sue Howard , freebsd-arch@freebsd.org Subject: Re: Kernel Dump X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2005 21:51:39 -0000 Wilkinson, Alex wrote: > 0n Wed, Jun 22, 2005 at 11:23:25PM -0700, Peter Wemm wrote: > > >I've just rewritten the AMD64 crashdump support to use ELF like ia64. > >In fact, I reused most of the ia64 code. We ran into serious problems > >at work, first on the amd64 platform and now also the i386 platform. > >The problem is that x86 machines are increasinly having memory holes. > >The simplistic dump code has no way to skip the memory hole and tries > >to dump things like the AGP frame buffer, pci card MMIO space, > >PCI-Express configuration space (this means accessing hardware!!) and > >so on. > > Curious, why is it that x86 creates memory holes in the first place ? > > - aW Some holes are mandated by the architecture. There is the classic hole from 640k to 1MB where the video framebuffer, option ROM, and BIOS goes. There is also the PCI memory hole from (typically) 3.75GB to 4GB where memio registers as well as platform features platform like the APIC are addressed. PCI Express adds a new hole at (typically) 3.5GB to 3.75GB for the extended config space registers. There are other holes, and most of them are dictated by the chipset. The BIOS SMAP table lists them, and you can see this table by doing a verbose boot. Scott