From owner-freebsd-arch@FreeBSD.ORG Sun Aug 17 21:27:10 2003 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 2969F37B401 for ; Sun, 17 Aug 2003 21:27:10 -0700 (PDT) Received: from web13404.mail.yahoo.com (web13404.mail.yahoo.com [216.136.175.62]) by mx1.FreeBSD.org (Postfix) with SMTP id CB02F43F85 for ; Sun, 17 Aug 2003 21:27:09 -0700 (PDT) (envelope-from giffunip@yahoo.com) Message-ID: <20030818042709.62687.qmail@web13404.mail.yahoo.com> Received: from [200.91.194.43] by web13404.mail.yahoo.com via HTTP; Mon, 18 Aug 2003 05:27:09 BST Date: Mon, 18 Aug 2003 05:27:09 +0100 (BST) From: "=?iso-8859-1?q?Pedro=20F.=20Giffuni?=" To: Nicolas Souchu MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: freebsd-arch@freebsd.org Subject: Re: Loadable VM pager 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, 18 Aug 2003 04:27:10 -0000 Hi; FWIW, I just wanted to mention... perhaps the only OS that has made all of it's components loadable in a similar way is SPIN: http://www.cs.washington.edu/research/projects/spin/www/ I understand they did it to take advantage of Modula's features (strict OO) that provided better security. cheers, Pedro. ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/ From owner-freebsd-arch@FreeBSD.ORG Mon Aug 18 00:16:43 2003 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 E475237B401 for ; Mon, 18 Aug 2003 00:16:42 -0700 (PDT) Received: from sohgo.tanimura.dyndns.org (IP1A1247.kng.mesh.ad.jp [61.203.80.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D53243FB1 for ; Mon, 18 Aug 2003 00:16:40 -0700 (PDT) (envelope-from tanimura@tanimura.dyndns.org) Received: from sohgo.tanimura.dyndns.org (localhost [IPv6:::1]) ESMTP id h7I7GIFN016727 ; Mon, 18 Aug 2003 16:16:18 +0900 (JST) Received: (from uucp@localhost) (8.12.9/3.7W-submit-carrots-Tokyu-Meguro) with UUCP id h7I7GH5O016726 ; Mon, 18 Aug 2003 16:16:17 +0900 (JST) Received: from urban.nkth.tanimura.dyndns.org (localhost [IPv6:::1]) with ESMTP id h7I7DQPE005765 ; Mon, 18 Aug 2003 16:13:26 +0900 (JST) Message-Id: <200308180713.h7I7DQPE005765@urban> Date: Mon, 18 Aug 2003 16:13:26 +0900 From: Seigo Tanimura To: arch@freebsd.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 MULE XEmacs/21.4 (patch 13) (Rational FORTRAN) (i386--freebsd) Organization: My Home MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: Seigo Tanimura Subject: Embedding a vnode type to its interlock mutex type 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, 18 Aug 2003 07:16:43 -0000 In short: A vnode should embed its type name (VREG, VCHR, etc.) in the type of the interlock mutex to avoid a false LOR alarm by Witness. The Details: With my p4 branch (tanimura_socket), I get a LOR shown below: --- v --- LOR log --- v --- lock order reversal 1st 0xfffff800262faa90 local rcv (local rcv) @ kern/uipc_socket.c:1250 2nd 0xc03c9a08 vm page queue mutex (vm page queue mutex) @ kern/uipc_cow.c:88 Stack backtrace: _mtx_lock_flags() at _mtx_lock_flags+0x9c socow_iodone() at socow_iodone+0x1c m_free() at m_free+0xf4 soreceive() at soreceive+0xe50 soo_read() at soo_read+0x78 dofileread() at dofileread+0x60 read() at read+0x3c syscall() at syscall+0x280 --- ^ --- LOR log --- ^ --- where the lock order is: --- v --- lock order by Witness --- v --- 4 pseudofs_vncache -- last acquired @ fs/pseudofs/pseudofs_vncache.c:227 5 mntvnode -- last acquired @ nfsclient/nfs_vfsops.c:1014 13 vnode interlock -- last acquired @ nfsclient/nfs_vfsops.c:1010 14 Syncer mtx -- last acquired @ kern/vfs_subr.c:1798 14 spechash -- last acquired @ kern/vfs_subr.c:2009 14 vnode_free_list -- last acquired @ kern/vfs_subr.c:760 14 local snd -- last acquired @ kern/uipc_socket.c:2173 15 local rcv -- last acquired @ kern/uipc_socket.c:2174 16 mbuf PCPU list lock -- last acquired @ kern/subr_mbuf.c:926 17 mbuf subsystem general lists lock -- last acquired @ kern/subr_mbuf.c:676 16 Malloc Stats -- last acquired @ kern/kern_malloc.c:324 16 sleep mtxpool -- last acquired @ kern/kern_prot.c:1686 16 socket generation -- last acquired @ kern/uipc_socket.c:263 16 sellck -- last acquired @ kern/sys_generic.c:816 16 UMA pcpu -- (already displayed) 10 vm object_list -- last acquired @ vm/vm_object.c:621 11 kmem object -- last acquired @ vm/vm_meter.c:179 12 vm page queue mutex -- last acquired @ vm/vm_pageout.c:1464 13 vnode interlock -- (already displayed) --- ^ --- lock order by Witness --- ^ --- Witness yells out because: - vm page queue mutex is immediately followed by vnode interlock, and - local rcv (the receive lock of an AF_LOCAL socket) is locked after vnode interlock in another place. Witness seems to thus presume that vm page queue mutex should have been acquired before local rcv. Although Witness treats this as a LOR, I believe this should be safe because AF_LOCAL sockets and VSOCK vnodes should not be used during vm operation. If we distinguished the interlocks for VSOCK vnodes from the ones for VREG (or VCHR), then there would be two lock orders: vm page queue mutex VREG/VCHR vnode interlock Syncer mtx spechash : : and VSOCK vnode interlock local snd local rcv vm page queue mutex : : They should safely coexist with each other. In order to accomplish that, the type of a mutex must be changed when the type of a vnode is changed. While it might work to just destroy and reinit the interlock of a vnode, those operations are likely to be overdoing because the type of a mutex is meaningful for only Witness. It would hence be better for Witness to provide an API to change the type of an inited mutex. For sockets, I implemented a trick to change lock types quite a few days ago. The idea is to embed the address family name to the types of socket locks. It solved almost all of the false LOR alerts for routing sockets, where a routing socket may need to be altered during sending from an inet or inet6 socket. It is quite easy for sockets to change its lock type because a socket is always freed when it is closed. Comments? -- Seigo Tanimura From owner-freebsd-arch@FreeBSD.ORG Mon Aug 18 02:27:38 2003 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 4E32637B401 for ; Mon, 18 Aug 2003 02:27:30 -0700 (PDT) Received: from hysteria.spc.org (hysteria.spc.org [195.206.69.234]) by mx1.FreeBSD.org (Postfix) with SMTP id 0C7EC43F75 for ; Mon, 18 Aug 2003 02:27:29 -0700 (PDT) (envelope-from bms@hysteria.spc.org) Received: (qmail 15883 invoked by uid 5013); 18 Aug 2003 09:24:34 -0000 Date: Mon, 18 Aug 2003 10:24:34 +0100 From: Bruce M Simpson To: Seigo Tanimura Message-ID: <20030818092434.GB2392@spc.org> References: <200308180713.h7I7DQPE005765@urban> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200308180713.h7I7DQPE005765@urban> User-Agent: Mutt/1.4.1i Organization: SPC cc: arch@freebsd.org Subject: Re: Embedding a vnode type to its interlock mutex type 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, 18 Aug 2003 09:27:39 -0000 On Mon, Aug 18, 2003 at 04:13:26PM +0900, Seigo Tanimura wrote: > In short: A vnode should embed its type name (VREG, VCHR, etc.) in the > type of the interlock mutex to avoid a false LOR alarm by Witness. I think I may have run into something similar with VM mutexes, but need to sit down and perform more in-depth testing to be sure about this. It does appear as though WITNESS only checks the name of the mutex, not the address of the mutex, which would presumably be a suitable key to differentiate them uniquely. BMS From owner-freebsd-arch@FreeBSD.ORG Mon Aug 18 11:38:16 2003 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 B870937B401 for ; Mon, 18 Aug 2003 11:38:14 -0700 (PDT) Received: from mail.speakeasy.net (mail9.speakeasy.net [216.254.0.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1087E43F85 for ; Mon, 18 Aug 2003 11:38:12 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 24042 invoked from network); 18 Aug 2003 18:38:10 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 18 Aug 2003 18:38:10 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h7IIc79s085638; Mon, 18 Aug 2003 14:38:08 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20030818092434.GB2392@spc.org> Date: Mon, 18 Aug 2003 14:38:31 -0400 (EDT) From: John Baldwin To: Bruce M Simpson cc: arch@freebsd.org cc: Seigo Tanimura Subject: Re: Embedding a vnode type to its interlock mutex type 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, 18 Aug 2003 18:38:16 -0000 On 18-Aug-2003 Bruce M Simpson wrote: > On Mon, Aug 18, 2003 at 04:13:26PM +0900, Seigo Tanimura wrote: >> In short: A vnode should embed its type name (VREG, VCHR, etc.) in the >> type of the interlock mutex to avoid a false LOR alarm by Witness. > > I think I may have run into something similar with VM mutexes, but need > to sit down and perform more in-depth testing to be sure about this. > > It does appear as though WITNESS only checks the name of the mutex, not > the address of the mutex, which would presumably be a suitable key to > differentiate them uniquely. This is intentional. Assume I have a lock A and two processes P1 and P2 each with a mutex. Now assume the following code paths: foo(P) { ... lock(A); lock(P->p_mtx); ... } bar(P) { ... lock(P->p_mtx); lock(A) ... } And assume the following is executed: foo(P1) bar(P2) Should that be a lock order reversal? I think it should be, because bar() might be called on P1 later or foo() on P2. If you only use lock addresses, then witness will not catch that reversal. Witness intentionally defines orders between groups of locks. Note that you can provide witness with a different name besides the individual mutex name via the 3rd argument to mtx_init(). See the MTX_NETWORK_LOCK for example which is used as the class for all network driver locks. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Mon Aug 18 12:59:15 2003 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 DFCE937B401 for ; Mon, 18 Aug 2003 12:59:15 -0700 (PDT) Received: from mail.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 064D2440E7 for ; Mon, 18 Aug 2003 12:59:15 -0700 (PDT) (envelope-from trb@FreeBSD.org) Received: (qmail 1332 invoked from network); 18 Aug 2003 19:59:14 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 18 Aug 2003 19:59:14 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h7IJxC9s086008; Mon, 18 Aug 2003 15:59:12 -0400 (EDT) (envelope-from trb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Mon, 18 Aug 2003 15:59:36 -0400 (EDT) From: Technical Review Board To: arch@FreeBSD.org Subject: [TRB] timer0 frequency change code removal 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, 18 Aug 2003 19:59:16 -0000 The TRB has been asked to resolve a dispute over the removal of the timer0 frequency adjusting clock code and the pcaudio driver. The TRB is considering the case and welcomes concise position e-mails containing technical reasons for or against the removal of this code. Please send such e-mails to the TRB. Thanks. -- John Baldwin (wearing my TRB hat) From owner-freebsd-arch@FreeBSD.ORG Mon Aug 18 18:51:58 2003 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 202F837B401; Mon, 18 Aug 2003 18:51:58 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2B2543F75; Mon, 18 Aug 2003 18:51:56 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (rwcrmhc12) with ESMTP id <20030819015155014003mnule>; Tue, 19 Aug 2003 01:51:55 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA52659; Mon, 18 Aug 2003 18:51:54 -0700 (PDT) Date: Mon, 18 Aug 2003 18:51:52 -0700 (PDT) From: Julian Elischer To: Technical Review Board In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@FreeBSD.org Subject: Re: [TRB] timer0 frequency change code removal 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, 19 Aug 2003 01:51:58 -0000 Hmm do I have to restate it? 1/ The original HEADSUP said it would remove the pca device. No mention was made of removing the underlying clockspeed code. My first objection was that it wouod be a pitty because a) It was a cute trick I sometimes used on machines with no soundcard that indicated some people have too much spare time :-) b) It was the best (only) example code on how to use the clock-speedup code, that I occasionally used and had heard of other using. It was then revealed that all clock-speedup code would be removed (acquire_timer[012]() etc.) in a stealth axing, not just pcaudio. My objection was then suitably enlarged to note that: a) This was a "known" ABI and the BSD tradition was to give one full release notice of deprecation of an API/ABI. (i.e remove it MAYBE for 6.0 if it had a major deliterious impact on the system) b) There had been some talk over the years of people using it for this and that and such people would probably not be aware of its removal until they hit it when upgrading. There was no attempt to find if there are serious users of the function (a mail to -current doesn't even begin to cover the userbase). c) No alternative functionality was being offered for people who wanted a variable frequency interrupt source. (i.e functionality was being removed with no increase in functionality). JHB pointed out that a major problem PHK claimed, could be solved with a relatively simple patch. At this time I believe that much of the code has already been removed without reviewing objections. (unless I missed the reversion) FreeBSD could get by without this code but it is not neccesary to remove it in such an abrupt manner, Nor do I believe it has any major deliterious effect on the system). The userbase was not even considerred and I think that that needs to be done before it can be decided. On Mon, 18 Aug 2003, Technical Review Board wrote: > The TRB has been asked to resolve a dispute over the removal of > the timer0 frequency adjusting clock code and the pcaudio driver. > The TRB is considering the case and welcomes concise position > e-mails containing technical reasons for or against the removal of > this code. Please send such e-mails to the TRB. Thanks. > > -- > John Baldwin (wearing my TRB hat) > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Tue Aug 19 15:59:20 2003 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 BDA2E16A4BF; Tue, 19 Aug 2003 15:59:20 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CEFF43F3F; Tue, 19 Aug 2003 15:59:18 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange.errno.com (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id h7JMxG7N022475 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 19 Aug 2003 15:59:17 -0700 (PDT) (envelope-from sam@errno.com) Date: Tue, 19 Aug 2003 15:59:27 -0700 From: Sam Leffler To: freebsd-net-@freebsd.org, freebsd-arch@freebsd.org Message-ID: <447450569.1061308767@melange.errno.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: HEADS UP: network locking work going on 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, 19 Aug 2003 22:59:21 -0000 I'm actively working on improving the network performance of -current. Much of this work involves removing Giant from the network stack. I've already been in touch with many developers that are working in this area; this note is to insure "everyone" is aware. If your are actively working on stuff related to the network code and I haven't already corresponded with you; please let me know so we can coordinate our work--I have no interest in duplicating the efforts of others. Otherwise, if you are working in this area I'd appreciate knowing about any significant changes planned that might affect what I'm doing. As to the work itself, the overall goal is to bring the performance for "normal network use" back to at least that of -stable. This is to be done in time for the 5.2 release though the specifics of what is included in 5.2 are to be determined. Obviously the main work here is to remove Giant and to that end I've already made a pass over the following areas (in no specific order): raw sockets routing table (except multicast routing) fast ipsec fast forwarding bridge ipfw 802.11 layer fxp, em, sis, wi, and ath drivers For the most part I've been working "from the bottom up". I run numerous systems w/o Giant in my network drivers and with the "middleware" Giant free (e.g. I have a soekris 4501 running bridge+ipfw w/o Giant). At the moment I am concentrating on correctness and not performance so I cannot report how much improvement there is. I'll be posting all significant changes for review before they are committed. Expect the first wave of stuff today and tomorrow. Developers can "play along" by checking out the sam_netperf branch in the p4 repo. Once the work on the lower layer is stable I'll be turning my attention to the upper layers of the network and to IPv6 and NFS. There's plenty of work to go around, so if you're interested in participating please let me know. Sam From owner-freebsd-arch@FreeBSD.ORG Tue Aug 19 16:21:59 2003 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 044A316A4C0; Tue, 19 Aug 2003 16:21:59 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-64-169-107-97.dsl.lsan03.pacbell.net [64.169.107.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15A9D43FE9; Tue, 19 Aug 2003 16:21:58 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id 9FCC866B04; Tue, 19 Aug 2003 16:21:56 -0700 (PDT) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id 4D99EA56; Tue, 19 Aug 2003 16:21:56 -0700 (PDT) Date: Tue, 19 Aug 2003 16:21:56 -0700 From: Kris Kennaway To: Sam Leffler Message-ID: <20030819232156.GA80650@rot13.obsecurity.org> References: <447450569.1061308767@melange.errno.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <447450569.1061308767@melange.errno.com> User-Agent: Mutt/1.4.1i cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: HEADS UP: network locking work going on 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, 19 Aug 2003 23:21:59 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 19, 2003 at 03:59:27PM -0700, Sam Leffler wrote: > I'm actively working on improving the network performance of -current.=20 8b d8 88 Y8, ,8P 88 Y8, ,8P 88 "8aa8" ,adPPYYba, 8b d8 88 `88' "" `Y8 `8b d8' 88 88 ,adPPPPP88 `8b d8' "" 88 88, ,88 `8b,d8' aa 88 `"8bbdP"Y8 Y88' 88 d8' d8' :-) Kris --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/QrEUWry0BWjoQKURAlHiAJ9eZmpoclbob89QUieyfX8fntuVjwCfV8d4 Pk6a+0aF8tGu+D/Cxx0cP7o= =KrZB -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From owner-freebsd-arch@FreeBSD.ORG Tue Aug 19 19:13:35 2003 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 24E9516A4BF for ; Tue, 19 Aug 2003 19:13:35 -0700 (PDT) Received: from smtp.mho.com (smtp.mho.net [64.58.4.6]) by mx1.FreeBSD.org (Postfix) with SMTP id EEDE143FD7 for ; Tue, 19 Aug 2003 19:13:33 -0700 (PDT) (envelope-from scottl@freebsd.org) Received: (qmail 98796 invoked by uid 1002); 20 Aug 2003 02:13:33 -0000 Received: from unknown (HELO freebsd.org) (64.58.1.252) by smtp.mho.net with SMTP; 20 Aug 2003 02:13:33 -0000 Message-ID: <3F42D8EC.1010706@freebsd.org> Date: Tue, 19 Aug 2003 20:11:56 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Leffler References: <447450569.1061308767@melange.errno.com> In-Reply-To: <447450569.1061308767@melange.errno.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net-@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: HEADS UP: network locking work going on 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, 20 Aug 2003 02:13:35 -0000 Sam Leffler wrote: > I'm actively working on improving the network performance of -current. > Much of this work involves removing Giant from the network stack. I've > already been in touch with many developers that are working in this > area; this note is to insure "everyone" is aware. If your are actively > working on stuff related to the network code and I haven't already > corresponded with you; please let me know so we can coordinate our > work--I have no interest in duplicating the efforts of others. > Otherwise, if you are working in this area I'd appreciate knowing about > any significant changes planned that might affect what I'm doing. > > As to the work itself, the overall goal is to bring the performance for > "normal network use" back to at least that of -stable. This is to be > done in time for the 5.2 release though the specifics of what is > included in 5.2 are to be determined. Obviously the main work here is > to remove Giant and to that end I've already made a pass over the > following areas (in no specific order): > > raw sockets > routing table (except multicast routing) > fast ipsec > fast forwarding > bridge > ipfw > 802.11 layer > fxp, em, sis, wi, and ath drivers > Excellent! Is there any consideration for running some hardware drivers with Giant while they are converted? Scott From owner-freebsd-arch@FreeBSD.ORG Tue Aug 19 21:09:27 2003 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 168D016A4BF; Tue, 19 Aug 2003 21:09:27 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47E7B43F93; Tue, 19 Aug 2003 21:09:26 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange.errno.com (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id h7K49N7N023724 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 19 Aug 2003 21:09:25 -0700 (PDT) (envelope-from sam@errno.com) Date: Tue, 19 Aug 2003 21:09:35 -0700 From: Sam Leffler To: Scott Long Message-ID: <466057615.1061327374@melange.errno.com> In-Reply-To: <3F42D8EC.1010706@freebsd.org> References: <447450569.1061308767@melange.errno.com> <3F42D8EC.1010706@freebsd.org> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: HEADS UP: network locking work going on 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, 20 Aug 2003 04:09:27 -0000 > Is there any consideration for running some hardware drivers with Giant > while they are converted? I have seen no issues so far mixing drivers w/ and w/o Giant. But that won't be true once drivers stop inheriting Giant when entered "from the top". It's not clear to me that it's any more work to lock drivers than to provide some sort of compatibility shims. Regardless this won't be an issue for a while. Mind you I am still tracking at least one nasty bug... Sam From owner-freebsd-arch@FreeBSD.ORG Wed Aug 20 01:37:56 2003 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 C97FC16A4BF for ; Wed, 20 Aug 2003 01:37:55 -0700 (PDT) Received: from mercury.bitband.com (mercury.bitband.com [62.0.22.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FE5F43FE5 for ; Wed, 20 Aug 2003 01:37:54 -0700 (PDT) (envelope-from VaMailArmor@mercury.bitband.com) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by mercury.bitband.com (8.12.8/8.12.5) with ESMTP id h7K9itCA016240 for ; Wed, 20 Aug 2003 12:44:56 +0300 Date: Wed, 20 Aug 2003 12:44:55 +0300 Message-Id: <200308200944.h7K9itCA016240@mercury.bitband.com> From: VaMailArmor@mercury.bitband.com To: freebsd-arch@FreeBSD.org References: <200308200835.h7K8Zhm14827@mx10.netvision.net.il> Subject: Vexira ALERT [your mail: "Thank you!"] 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, 20 Aug 2003 08:37:56 -0000 * * * * * * * * * * * * * * * Vexira ALERT * * * * * * * * * * * * * * * This version of Vexira MailArmor is licensed and full featured. Vexira has detected the following in a mail from your address: Worm/Sobig.F virus The mail was not delivered. Your computer may be infected with a virus! Please visit Central Command at http://www.centralcommand.com and obtain a copy of Vexira AntiVirus now. Mail-Info: --8<-- Message-Id: <200308200835.h7K8Zhm14827@mx10.netvision.net.il> From: To: <3829128F.65FF7F7C@bitband.com> Date: Wed, 20 Aug 2003 1:30:35 --0700 Subject: Thank you! --8<-- -- Vexira AntiVirus for Linux, OpenBSD, FreeBSD Virus Protection for the Real World (TM). Central Command http://www.centralcommand.com From owner-freebsd-arch@FreeBSD.ORG Wed Aug 20 04:24:49 2003 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 4124516A4C0 for ; Wed, 20 Aug 2003 04:24:49 -0700 (PDT) Received: from hysteria.spc.org (hysteria.spc.org [195.206.69.234]) by mx1.FreeBSD.org (Postfix) with SMTP id 2ACF643FE3 for ; Wed, 20 Aug 2003 04:24:43 -0700 (PDT) (envelope-from bms@hysteria.spc.org) Received: (qmail 20324 invoked by uid 5013); 20 Aug 2003 11:21:45 -0000 Date: Wed, 20 Aug 2003 12:21:45 +0100 From: Bruce M Simpson To: Sam Leffler , Bill Fenner , Jake Burkholder , mini@freebsd.org Message-ID: <20030820112145.GB11682@spc.org> Mail-Followup-To: Bruce M Simpson , Sam Leffler , Bill Fenner , Jake Burkholder , mini@freebsd.org, freebsd-net@freebsd.org, freebsd-arch@freebsd.org References: <447450569.1061308767@melange.errno.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ALfTUftag+2gvp1h" Content-Disposition: inline In-Reply-To: <447450569.1061308767@melange.errno.com> User-Agent: Mutt/1.4.1i Organization: SPC cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: 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, 20 Aug 2003 11:24:49 -0000 --ALfTUftag+2gvp1h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Aug 19, 2003 at 03:59:27PM -0700, Sam Leffler wrote: > this note is to insure "everyone" is aware. If your are actively working > on stuff related to the network code and I haven't already corresponded > with you; please let me know so we can coordinate our work--I have no > interest in duplicating the efforts of others. Otherwise, if you are > working in this area I'd appreciate knowing about any significant changes > planned that might affect what I'm doing. I'm preparing to commit the attached, any objections? (As soon as Jake wakes up, anyway ;). Was loosely following the flow of things from BSD/OS; it doesn't appear to impact on locking but I'm grateful for more expert review in this area. mini@ has looked over it and doesn't see any immediate problems. provisional log message: Add the IP_ONESBCAST option, to enable undirected IP broadcasts to be sent on specific interfaces. This is required by aodvd, and may in future help us in getting rid of the requirement for BPF from our import of isc-dhcp. Suggested by: fenestro Reviewed by: mini Referenced by: wstevens Obtained from: BSD/OS BMS --ALfTUftag+2gvp1h Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="onesbc.col.diff" Generated by diffcoll on Wed 20 Aug 2003 12:08:21 BST diff -uN src/sys/netinet/in.h.orig src/sys/netinet/in.h --- /usr/src/sys/netinet/in.h.orig Tue Aug 19 22:57:16 2003 +++ /usr/src/sys/netinet/in.h Wed Aug 20 12:08:16 2003 @@ -388,6 +388,8 @@ #define IP_IPSEC_POLICY 21 /* int; set/get security policy */ #define IP_FAITH 22 /* bool; accept FAITH'ed connections */ +#define IP_ONESBCAST 23 /* bool: send all-ones broadcast */ + #define IP_FW_ADD 50 /* add a firewall rule to chain */ #define IP_FW_DEL 51 /* delete a firewall rule from chain */ #define IP_FW_FLUSH 52 /* flush firewall rule chain */ diff -uN src/sys/netinet/ip_var.h.orig src/sys/netinet/ip_var.h --- /usr/src/sys/netinet/ip_var.h.orig Tue Aug 19 23:08:49 2003 +++ /usr/src/sys/netinet/ip_var.h Wed Aug 20 12:07:48 2003 @@ -139,6 +139,7 @@ /* flags passed to ip_output as last parameter */ #define IP_FORWARDING 0x1 /* most of ip header exists */ #define IP_RAWOUTPUT 0x2 /* raw ip header exists */ +#define IP_SENDONES 0x4 /* send all-ones broadcast */ #define IP_ROUTETOIF SO_DONTROUTE /* bypass routing tables */ #define IP_ALLOWBROADCAST SO_BROADCAST /* can send broadcast packets */ diff -uN src/sys/netinet/in_pcb.h.orig src/sys/netinet/in_pcb.h --- /usr/src/sys/netinet/in_pcb.h.orig Tue Aug 19 23:00:47 2003 +++ /usr/src/sys/netinet/in_pcb.h Wed Aug 20 12:07:48 2003 @@ -142,6 +142,7 @@ #define INP_IPV6 0x2 #define INP_IPV6PROTO 0x4 /* opened under IPv6 protocol */ #define INP_TIMEWAIT 0x8 /* .. probably doesn't go here */ +#define INP_ONESBCAST 0x10 /* send all-ones broadcast */ u_char inp_ip_ttl; /* time to live proto */ u_char inp_ip_p; /* protocol proto */ diff -uN src/sys/netinet/ip_output.c.orig src/sys/netinet/ip_output.c --- /usr/src/sys/netinet/ip_output.c.orig Tue Aug 19 23:01:37 2003 +++ /usr/src/sys/netinet/ip_output.c Wed Aug 20 12:07:48 2003 @@ -469,6 +469,8 @@ error = EMSGSIZE; goto bad; } + if (flags & IP_SENDONES) + ip->ip_dst.s_addr = INADDR_BROADCAST; m->m_flags |= M_BCAST; } else { m->m_flags &= ~M_BCAST; @@ -1427,6 +1429,7 @@ case IP_RECVTTL: case IP_RECVIF: case IP_FAITH: + case IP_ONESBCAST: error = sooptcopyin(sopt, &optval, sizeof optval, sizeof optval); if (error) @@ -1469,6 +1472,10 @@ case IP_FAITH: OPTSET(INP_FAITH); break; + + case IP_ONESBCAST: + OPTSET(INP_ONESBCAST); + break; } break; #undef OPTSET @@ -1562,6 +1569,7 @@ case IP_RECVIF: case IP_PORTRANGE: case IP_FAITH: + case IP_ONESBCAST: switch (sopt->sopt_name) { case IP_TOS: @@ -1605,6 +1613,10 @@ case IP_FAITH: optval = OPTBIT(INP_FAITH); + break; + + case IP_ONESBCAST: + optval = OPTBIT(INP_ONESBCAST); break; } error = sooptcopyout(sopt, &optval, sizeof optval); diff -uN src/sys/netinet/raw_ip.c.orig src/sys/netinet/raw_ip.c --- /usr/src/sys/netinet/raw_ip.c.orig Tue Aug 19 23:36:29 2003 +++ /usr/src/sys/netinet/raw_ip.c Wed Aug 20 12:07:48 2003 @@ -322,6 +322,9 @@ ipstat.ips_rawout++; } + if (inp->inp_flags & INP_ONESBCAST) + flags |= IP_SENDONES; + return (ip_output(m, inp->inp_options, &inp->inp_route, flags, inp->inp_moptions, inp)); } diff -uN src/sys/netinet/udp_usrreq.c.orig src/sys/netinet/udp_usrreq.c --- /usr/src/sys/netinet/udp_usrreq.c.orig Tue Aug 19 22:46:26 2003 +++ /usr/src/sys/netinet/udp_usrreq.c Wed Aug 20 12:07:48 2003 @@ -693,6 +693,7 @@ struct cmsghdr *cm; struct sockaddr_in *sin, src; int error = 0; + int ipflags; u_short fport, lport; #ifdef MAC @@ -821,6 +822,10 @@ ui->ui_dport = fport; ui->ui_ulen = htons((u_short)len + sizeof(struct udphdr)); + ipflags = inp->inp_socket->so_options & (SO_DONTROUTE | SO_BROADCAST); + if (inp->inp_flags & INP_ONESBCAST) + ipflags |= IP_SENDONES; + /* * Set up checksum and output datagram. */ @@ -837,8 +842,7 @@ ((struct ip *)ui)->ip_tos = inp->inp_ip_tos; /* XXX */ udpstat.udps_opackets++; - error = ip_output(m, inp->inp_options, &inp->inp_route, - (inp->inp_socket->so_options & (SO_DONTROUTE | SO_BROADCAST)), + error = ip_output(m, inp->inp_options, &inp->inp_route, ipflags, inp->inp_moptions, inp); return (error); diff -uN src/share/man/man4/ip.4.orig src/share/man/man4/ip.4 --- /usr/src/share/man/man4/ip.4.orig Tue Aug 19 23:40:22 2003 +++ /usr/src/share/man/man4/ip.4 Wed Aug 20 12:07:48 2003 @@ -175,6 +175,47 @@ .Xr sendmsg 2 . .Pp If the +.Dv IP_ONESBCAST +option is enabled on a +.Dv SOCK_DGRAM +or a +.Dv SOCK_RAW +socket, the destination address of outgoing +broadcast datagrams on that socket will be forced +to the undirected broadcast address, +.Dv INADDR_BROADCAST , +before transmission. +This is in contrast to the default behavior of the +system, which is to transmit undirected broadcasts +via the first network interface with the +.Dv IFF_BROADCAST flag set. +.Pp +This option allows applications to choose which +interface is used to transmit an undirected broadcast +datagram. +For example, the following code would force an +undirected broadcast to be transmitted via the interface +configured with the broadcast address 192.168.2.255: +.Bd -literal +char msg[512]; +struct sockaddr_in sin; +u_char onesbcast = 1; /* 0 = disable (default), 1 = enable */ + +setsockopt(s, IPPROTO_IP, IP_ONESBCAST, &onesbcast, sizeof(onesbcast)); +sin.sin_addr.s_addr = inet_addr("192.168.2.255"); +sin.sin_port = htons(1234); +sendto(s, msg, sizeof(msg), 0, &sin, sizeof(sin)); +.Ed +.Pp +It is the application's responsibility to set the +.Dv IP_TTL option +to an appropriate value in order to prevent broadcast storms. +The application must have sufficient credentials to set the +.Dv SO_BROADCAST +socket level option, otherwise the +.Dv IP_ONESBCAST option has no effect. +.Pp +If the .Dv IP_RECVTTL option is enabled on a .Dv SOCK_DGRAM --ALfTUftag+2gvp1h-- From owner-freebsd-arch@FreeBSD.ORG Wed Aug 20 08:42:54 2003 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 9F62616A4C0; Wed, 20 Aug 2003 08:42:54 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF54243FE1; Wed, 20 Aug 2003 08:42:53 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange.errno.com (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id h7KFgn7N026500 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 20 Aug 2003 08:42:53 -0700 (PDT) (envelope-from sam@errno.com) Date: Wed, 20 Aug 2003 08:43:02 -0700 From: Sam Leffler To: freebsd-net@freebsd.org, freebsd-arch@freebsd.org Message-ID: <507665634.1061368982@melange.errno.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: CFR: fastforwarding locking 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, 20 Aug 2003 15:42:54 -0000 http://www.freebsd.org/~sam/fastforward.patch These lock the fast forwarding hash table with a lock per hash bucket. There is one known issue with these changes: a LOR with the bridge code caused by holding a lock across the call to forward the packet. Also, some statistics are not consistently updated. Beware of overlap with routing table locking changes. Sam From owner-freebsd-arch@FreeBSD.ORG Wed Aug 20 08:53:43 2003 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 A441B16A4C0; Wed, 20 Aug 2003 08:53:43 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id E51B043F93; Wed, 20 Aug 2003 08:53:42 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange.errno.com (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id h7KFrb7N026573 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 20 Aug 2003 08:53:41 -0700 (PDT) (envelope-from sam@errno.com) Date: Wed, 20 Aug 2003 08:53:49 -0700 From: Sam Leffler To: freebsd-net@freebsd.org, freebsd-arch@freebsd.org Message-ID: <508312264.1061369629@melange.errno.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: CFR: fast ipsec locking 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, 20 Aug 2003 15:53:44 -0000 http://www.freebsd.org/~sam/fastipsec.patch These changes add locking and cleanup some of the infrastructure; e.g. to do better accounting of dynamically allocated data structures. Basic operation is well-tested but I haven't done extensive testing of the re-keying (e.g. with racoon). There is one known performance bottleneck: the lock in the ipsecrequest structure is held for every outbound packet to guard against modification to the data structure. This looks to be fixable by redoing the SADB but won't happen for a while. Note that with these changes much of fast ipsec runs Giant-free because the crypto code is already Giant-free. I did some performance measurements a while back with this code and a Giant-free em driver and got netperf results over a h/w-accelerated 3DES+SHA1 tunnel that was about the same as -stable. Sam From owner-freebsd-arch@FreeBSD.ORG Wed Aug 20 08:55:21 2003 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 33E3916A4BF; Wed, 20 Aug 2003 08:55:21 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 643F743FCB; Wed, 20 Aug 2003 08:55:20 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange.errno.com (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id h7KFtJ7N026586 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 20 Aug 2003 08:55:19 -0700 (PDT) (envelope-from sam@errno.com) Date: Wed, 20 Aug 2003 08:55:32 -0700 From: Sam Leffler To: freebsd-net@freebsd.org, freebsd-arch@freebsd.org Message-ID: <508414881.1061369732@melange.errno.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: CFG: domain locking 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, 20 Aug 2003 15:55:21 -0000 http://www.freebsd.org/~sam/domain.patch These add locking to the list of domains. Sam From owner-freebsd-arch@FreeBSD.ORG Wed Aug 20 08:58:32 2003 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 7668016A4BF; Wed, 20 Aug 2003 08:58:32 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id CECDE43FA3; Wed, 20 Aug 2003 08:58:31 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange.errno.com (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id h7KFwS7N026592 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 20 Aug 2003 08:58:31 -0700 (PDT) (envelope-from sam@errno.com) Date: Wed, 20 Aug 2003 08:58:41 -0700 From: Sam Leffler To: freebsd-net@freebsd.org, freebsd-arch@freebsd.org Message-ID: <508604564.1061369921@melange.errno.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: CFG: raw socket locking 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, 20 Aug 2003 15:58:32 -0000 http://www.freebsd.org/~sam/rawsock.patch This locks the raw socket protocol control blocks using equivalent techniques to those used for udp, etc. There is one code restructuring done to simplify this work; equivalent to the one I added for udp. Note this change also removes the rip_olddiverterror sysctl. It was marked as "to be removed". I'll probably leave it alone and/or remove it in a separate pass. Sam From owner-freebsd-arch@FreeBSD.ORG Wed Aug 20 09:14:15 2003 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 0786F16A4BF; Wed, 20 Aug 2003 09:14:15 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D63943FBD; Wed, 20 Aug 2003 09:14:14 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange.errno.com (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id h7KGE77N026653 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 20 Aug 2003 09:14:13 -0700 (PDT) (envelope-from sam@errno.com) Date: Wed, 20 Aug 2003 09:14:19 -0700 From: Sam Leffler To: freebsd-net@freebsd.org, freebsd-arch@freebsd.org Message-ID: <509542533.1061370859@melange.errno.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: CFR: routing table locking 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, 20 Aug 2003 16:14:15 -0000 http://www.freebsd.org/~sam/rtentry.patch This is an extensive set of changes to lock routing table entries. There are some issues with these changes that will need to be resolved before committing the work. In particular the per-entry mutex is stored in the rtentry structure and this struct is visible to user applications like route(8). This must be fixed. For now I've #ifdef'd the mutex to be included only in the kernel. We'll either need to use an indirect reference to a mutex or, more likely, introduce an externalized version of struct rtentry to decouple kernel operation from user applications. It may be possible to jigger the code to make the lock in the entry be a leaf lock in which case we could use a mutex pool and a pointer to a mutex but I'm leaning more to decoupling the kernel from user apps as this has general benefits. These changes have been in use on 4 of my machines for several weeks. IPv6 has only been lightly tested. In general I consider the code very lightly tested so don't be surprised if you encounter issues. Also, because of the wide visibility of the routing table in the system I may have missed some uses that need locking. There are a couple of LOR issues to be resolved. In particular I recall there is one with the ARP cache. Another issue is that these changes do not include multicast routing. That code has been changing recently so I left it alone. I'm not well setup to test multicast routing so if someone with an existing setup is interested in tacking this please let me know. Note there is one API change buried in these diffs. I dropped the last parameter to rtredirect that allowed callers to receive a reference to the associated entry. This was not used in the system and introduced issues for locking. Sam From owner-freebsd-arch@FreeBSD.ORG Wed Aug 20 09:34:45 2003 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 785AC16A4BF; Wed, 20 Aug 2003 09:34:45 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC96A43F85; Wed, 20 Aug 2003 09:34:44 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange.errno.com (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id h7KGYe7N026721 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 20 Aug 2003 09:34:43 -0700 (PDT) (envelope-from sam@errno.com) Date: Wed, 20 Aug 2003 09:34:54 -0700 From: Sam Leffler To: freebsd-net@freebsd.org, freebsd-arch@freebsd.org Message-ID: <510776858.1061372094@melange.errno.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: CFR: bridge locking 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, 20 Aug 2003 16:34:45 -0000 http://www.freebsd.org/~sam/bridge.patch This patch adds locking and also overhauls the bridge code some to do things like replace explicit numbers with #defines and cleanup the debugging code. I also restructured the forwarding code to avoid grabbing the ifnet lock if possible and optimized the common case of bridging two interfaces. There are a couple of LOR issues to be resolved before it can be committed. In particular the output path has a LOR that can deadlock. I'm making it available for review now in case folks have other comments. Beware that buried in these changes are a renaming of the bridge MIB variables to be under a net.link.ether.bridge. node. Those changes will not be carried over into the committed code unless folks are interested (since it'll break lots of rc scripts). Note that drivers that operate Giant-free with bridging need to release their "driver lock" before passing packets up. Otherwise the up call can result in an immediate return through the start method and deadlock (unless the lock is marked to allow recursion, which should be eliminated if at all possible). I've made these modifications for the em, wi, and sis drivers but have not committed them. The fxp driver already does this and the ath driver has a totally different locking strategy where this doesn't occur. Short term dropping the lock around the up call will work but is suboptimal. Long term we may want to revise the locking strategy for drivers to eliminate this issue. This will likely be revisited when I get to more performance tuning (unless someone else does it--hint hint). One other minor change: I moved the printf "BRIDGE 020214 loaded" under bootverbose. Can anyone tell me what 020214 means? This code has been in "production use" on my interior firewall (a soekris box) for a week. This box runs with the sis driver Giant-free. Sam From owner-freebsd-arch@FreeBSD.ORG Wed Aug 20 09:40:38 2003 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 0AA9716A4BF; Wed, 20 Aug 2003 09:40:38 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CCE943FBF; Wed, 20 Aug 2003 09:40:37 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange.errno.com (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id h7KGeW7N026765 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 20 Aug 2003 09:40:36 -0700 (PDT) (envelope-from sam@errno.com) Date: Wed, 20 Aug 2003 09:40:44 -0700 From: Sam Leffler To: freebsd-net@freebsd.org, freebsd-arch@freebsd.org Message-ID: <511127492.1061372444@melange.errno.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: CFR: ipfw locking 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, 20 Aug 2003 16:40:38 -0000 http://www.freebsd.org/~sam/ipfw.patch These changes add locking. There are two locks: one for static rules and one for dynamic rules. The associated dummynet changes are not included as I haven't tested them yet. The locking scheme may need to be revised to use something like sx locks; this will be revisited in a later pass. I've been running with these changes for a week on my interior firewall, but they are very lightly tested and need a good review and more testing. I don't plan to commit them until they get more of each. Sam From owner-freebsd-arch@FreeBSD.ORG Wed Aug 20 10:23:57 2003 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 8404616A4BF; Wed, 20 Aug 2003 10:23:57 -0700 (PDT) Received: from b.mx.sonic.net (eth0.b.mx.sonic.net [209.204.159.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE71243FB1; Wed, 20 Aug 2003 10:23:56 -0700 (PDT) (envelope-from bmah@intruder.kitchenlab.org) Received: from intruder.kitchenlab.org (root@adsl-64-142-29-77.sonic.net [64.142.29.77]) by b.mx.sonic.net (8.12.9/8.12.7) with ESMTP id h7KHNjsX032054; Wed, 20 Aug 2003 10:23:55 -0700 Received: from intruder.kitchenlab.org (bmah@localhost [127.0.0.1]) h7KHNimh069232; Wed, 20 Aug 2003 10:23:44 -0700 (PDT) (envelope-from bmah@intruder.kitchenlab.org) Received: (from bmah@localhost) by intruder.kitchenlab.org (8.12.9/8.12.9/Submit) id h7KHNgtw069231; Wed, 20 Aug 2003 10:23:42 -0700 (PDT) (envelope-from bmah) Date: Wed, 20 Aug 2003 10:23:42 -0700 From: "Bruce A. Mah" To: Sam Leffler Message-ID: <20030820172342.GA69189@intruder.kitchenlab.org> References: <510776858.1061372094@melange.errno.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline In-Reply-To: <510776858.1061372094@melange.errno.com> User-Agent: Mutt/1.4.1i X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-url: http://www.employees.org/~bmah/ cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: CFR: bridge locking 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, 20 Aug 2003 17:23:57 -0000 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable If memory serves me right, Sam Leffler wrote: > One other minor change: I moved the printf "BRIDGE 020214 loaded" under= =20 > bootverbose. Can anyone tell me what 020214 means? I recently started using bridge(4) functionality and was wondering about this too. Based on the output of "cvs annotate" and "cvs log", I concluded that it was a datestamp used by Luigi to keep track of which version he was working with (on HEAD, this line was last touched in revision 1.45, which was committed on 15 February 2002). Bruce. --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/Q66e2MoxcVugUsMRAp3hAKCxM1N5I5KwFaUEh3raArnoSn2hRACgww6W uwUG6QGPqDjtslEME0Bn7h8= =YTgR -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi-- From owner-freebsd-arch@FreeBSD.ORG Wed Aug 20 10:29:37 2003 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 8E6C116A4BF; Wed, 20 Aug 2003 10:29:37 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF7CE43FBF; Wed, 20 Aug 2003 10:29:36 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (c-24-130-112-121.we.client2.attbi.com [24.130.112.121]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h7KHTYn29800; Wed, 20 Aug 2003 10:29:34 -0700 (PDT) Message-ID: <3F43AFFD.6080504@isi.edu> Date: Wed, 20 Aug 2003 10:29:33 -0700 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Leffler References: <510776858.1061372094@melange.errno.com> In-Reply-To: <510776858.1061372094@melange.errno.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070006010709090100050103" cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: CFR: bridge locking 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, 20 Aug 2003 17:29:37 -0000 This is a cryptographically signed message in MIME format. --------------ms070006010709090100050103 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sam Leffler wrote: > http://www.freebsd.org/~sam/bridge.patch > > This patch adds locking and also overhauls the bridge code some to do > things like replace explicit numbers with #defines and cleanup the > debugging code. This is only mildly related, but maybe someone feels like looking at this in addition to your locking changes... I have a PR about the bridge code sitting at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/41632; the latest patch is at http://www.isi.edu/larse/software/bridge.patch It does two things: 1. Disables bridging for IPv6. This is probably too aggressive, since bridging is only problematic for link-local packets, but it makes a routed IPv6 configuration coexist with a bridged IPv4 one. A much better fix would be an overhaul of the bridge code so that each bridge has a single link-local address, instead of one per physical interface. (Similar to how it should/must only have one IPv4 address, but link-locals are auto-assigned.) Essentially, make a bridge set its own pseudo interface. 2. It forwards a copy of bridged packets to bpfs attached to interfaces in the bridge set that have no carrier. This makes dhcpd work on an interface of a bridge set that is unplugged. Again, a much better fix would be to have bridge sets show up as pseudo interfaces that dhcpd's bpf can then listen on. I think you mentioned in the past that NetBSD (OpenBSD?) has bridge code that implements the pseudo-device approach? Lars PS: I needed both these changes for our Soekris-based "rent-a-subnet" box: http://www.isi.edu/tethernet/ -- Lars Eggert USC Information Sciences Institute --------------ms070006010709090100050103 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwp2bzANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDgwMTE3MjkyOVoX DTA0MDczMTE3MjkyOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMb7PuLXnwV+45vwlkgogdSijd5HVqUB14bWvoK0 MjWPnkLPMDMDEezdsMG1BPiZyNeqXlJJtEgdAK8H2Mc9/qLeJUq3CoAeD6Wrjq4QaxJBXgdS KcGDeQAZSDgwUJS9vx9+cXJVfLyOYxJ+CLBcO/eu8PvSi17lk6oeAbrskSGDu/Xi1o2SC4Qm l69k8xcZQEMQDodkIk/U5SJmsCRGGYdy7opHZb58yXI8eiIGp5MlgryFmmgrp1pg3OYzPOR9 zJjn7Pu1vsd97LM5hLnKrmNuYt02jLNSjr8HmpLyWCDZq4Jlfq1YgNYZZ4KOSxipia7Bxjcs nMOsxEWiolkVVT8CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEANRaPsUtrdJzTW0AMj/EQamqxOkZnzwnPWGryqskMKIf+OKa+eaXp zlBv8CHdffv9hrYpvzWUxk0WW+YJ2LRdd4fFiVGXZCGU60eYeZGf7Z8ORoexylJpvUuKZCE4 aPGY2/QZXDfOs1NE82Bhgltx59dpWfH2K0dxbpHslO8/IbowggM5MIICoqADAgECAgMKdm8w DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMzA4MDExNzI5MjlaFw0wNDA3MzExNzI5MjlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG+z7i158FfuOb 8JZIKIHUoo3eR1alAdeG1r6CtDI1j55CzzAzAxHs3bDBtQT4mcjXql5SSbRIHQCvB9jHPf6i 3iVKtwqAHg+lq46uEGsSQV4HUinBg3kAGUg4MFCUvb8ffnFyVXy8jmMSfgiwXDv3rvD70ote 5ZOqHgG67JEhg7v14taNkguEJpevZPMXGUBDEA6HZCJP1OUiZrAkRhmHcu6KR2W+fMlyPHoi BqeTJYK8hZpoK6daYNzmMzzkfcyY5+z7tb7HfeyzOYS5yq5jbmLdNoyzUo6/B5qS8lgg2auC ZX6tWIDWGWeCjksYqYmuwcY3LJzDrMRFoqJZFVU/AgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBADUWj7FLa3Sc01tADI/xEGpqsTpG Z88Jz1hq8qrJDCiH/jimvnml6c5Qb/Ah3X37/Ya2Kb81lMZNFlvmCdi0XXeHxYlRl2QhlOtH mHmRn+2fDkaHscpSab1LimQhOGjxmNv0GVw3zrNTRPNgYYJbcefXaVnx9itHcW6R7JTvPyG6 MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCnZvMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMDgyMDE3MjkzM1owIwYJKoZIhvcNAQkEMRYEFDBa8fpe4qiVmGVSLWhf MxOITpRMMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnZvMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMKdm8wDQYJKoZIhvcNAQEBBQAEggEAjooBdkmKJ1xru1gXIQ9bie3A8S5XnaI3gFUP xC4Pou4myhTwI/nCeprgohEbJpqEPYJhK8IW2sTeD6ociKI9/zsTXSGYxH6mP2SSXVff+dcj miMtwSqSO6aa1yBwK07CXkp0S33NkjuvmZWdgpz8gKnSgJW0UOeDE5Ce+hApRG+58B9uPsyj 62FBDH32BBcORLTRvYWQL1D/dezlb/PBe0fuHovPozrges3msAa7DaEm5mwySZjNhEd/IxGH 0iuCWbL8Hq8IHbS6PX+oSKC3Ns5mYID1c+nQLUj4CwrFdfHFfiRCBilSkXg2v/tmQgXIoADm 4TSs5D084Qfz795q7AAAAAAAAA== --------------ms070006010709090100050103-- From owner-freebsd-arch@FreeBSD.ORG Wed Aug 20 10:54:05 2003 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 6FDCD16A4BF; Wed, 20 Aug 2003 10:54:05 -0700 (PDT) Received: from mail.tcoip.com.br (erato.tco.net.br [200.220.254.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0953443FA3; Wed, 20 Aug 2003 10:54:03 -0700 (PDT) (envelope-from dcs@tcoip.com.br) Received: from tcoip.com.br ([10.0.2.6]) by mail.tcoip.com.br (8.11.6/8.11.6) with ESMTP id h7KHqlj31005; Wed, 20 Aug 2003 14:52:47 -0300 Message-ID: <3F43B56E.1070100@tcoip.com.br> Date: Wed, 20 Aug 2003 14:52:46 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030702 X-Accept-Language: en-us, en, pt-br, ja MIME-Version: 1.0 To: Lars Eggert References: <510776858.1061372094@melange.errno.com> <3F43AFFD.6080504@isi.edu> In-Reply-To: <3F43AFFD.6080504@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Sam Leffler cc: freebsd-arch@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: CFR: bridge locking 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, 20 Aug 2003 17:54:05 -0000 Lars Eggert wrote: > Sam Leffler wrote: > >> http://www.freebsd.org/~sam/bridge.patch >> >> This patch adds locking and also overhauls the bridge code some to do >> things like replace explicit numbers with #defines and cleanup the >> debugging code. > > > This is only mildly related, but maybe someone feels like looking at > this in addition to your locking changes... > > I have a PR about the bridge code sitting at > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/41632; the latest patch > is at http://www.isi.edu/larse/software/bridge.patch > > It does two things: > > 1. Disables bridging for IPv6. This is probably too aggressive, > since bridging is only problematic for link-local packets, but it > makes a routed IPv6 configuration coexist with a bridged IPv4 one. > > A much better fix would be an overhaul of the bridge code so that > each bridge has a single link-local address, instead of one per > physical interface. (Similar to how it should/must only have one IPv4 > address, but link-locals are auto-assigned.) Essentially, make > a bridge set its own pseudo interface. > > 2. It forwards a copy of bridged packets to bpfs attached to interfaces > in the bridge set that have no carrier. This makes dhcpd work on an > interface of a bridge set that is unplugged. > > Again, a much better fix would be to have bridge sets show up as > pseudo interfaces that dhcpd's bpf can then listen on. If you get bridge to send/receive packets to/from vlan interfaces attached to them, I'll be forever grateful. I've been trying to configure a setup where a firewall is connected to redundant switches, but no solution I found could handle the vlan attachments. :-( -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: Daniel.Capo@tco.net.br Daniel.Sobral@tcoip.com.br dcs@tcoip.com.br Outros: dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net Many pages make a thick book. From owner-freebsd-arch@FreeBSD.ORG Wed Aug 20 11:59:29 2003 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 A9BC916A4BF; Wed, 20 Aug 2003 11:59:29 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF43C43FDD; Wed, 20 Aug 2003 11:59:28 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h7KIxFrO049285; Wed, 20 Aug 2003 14:59:19 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)h7KIxEak049282; Wed, 20 Aug 2003 14:59:14 -0400 (EDT) Date: Wed, 20 Aug 2003 14:59:14 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Lars Eggert In-Reply-To: <3F43AFFD.6080504@isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Sam Leffler cc: freebsd-arch@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: CFR: bridge locking 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, 20 Aug 2003 18:59:30 -0000 On Wed, 20 Aug 2003, Lars Eggert wrote: > I think you mentioned in the past that NetBSD (OpenBSD?) has bridge code > that implements the pseudo-device approach? I had an older set of patches (4.x?) that implemented a bridgeX interface that saw all of the packets bridged by the bridge. However, it was just a pseudo-interface for the purposes of BPF -- it didn't carry a link local address, etc. I never tested for interop with IPv6. You can find a very old version of this at www.watson.org/~robert/freebsd/bridge.patch. It required some cleanup of the interactions between the bridge code and IPFW code that have probably since happened in the main tree as well, so the chances of this applying or working are effectively 0. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories From owner-freebsd-arch@FreeBSD.ORG Wed Aug 20 12:45:50 2003 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 1FC2616A4C0; Wed, 20 Aug 2003 12:45:50 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id C43F043F85; Wed, 20 Aug 2003 12:45:48 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (rwcrmhc13) with ESMTP id <2003082019422301500bnaj1e>; Wed, 20 Aug 2003 19:42:23 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA74511; Wed, 20 Aug 2003 12:42:20 -0700 (PDT) Date: Wed, 20 Aug 2003 12:42:19 -0700 (PDT) From: Julian Elischer To: Robert Watson In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Sam Leffler cc: freebsd-net@freebsd.org cc: Lars Eggert cc: freebsd-arch@freebsd.org Subject: Re: CFR: bridge locking 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, 20 Aug 2003 19:45:50 -0000 On Wed, 20 Aug 2003, Robert Watson wrote: > > On Wed, 20 Aug 2003, Lars Eggert wrote: > > > I think you mentioned in the past that NetBSD (OpenBSD?) has bridge code > > that implements the pseudo-device approach? FreeBSD has both. If you use netgraph bridging then you are using a more "link level device" like approach. > > I had an older set of patches (4.x?) that implemented a bridgeX interface > that saw all of the packets bridged by the bridge. However, it was just a > pseudo-interface for the purposes of BPF -- it didn't carry a link local > address, etc. I never tested for interop with IPv6. You can find a very > old version of this at www.watson.org/~robert/freebsd/bridge.patch. It > required some cleanup of the interactions between the bridge code and IPFW > code that have probably since happened in the main tree as well, so the > chances of this applying or working are effectively 0. :-) > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Network Associates Laboratories > > _______________________________________________ > 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 Wed Aug 20 12:51:07 2003 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 5542216A4BF; Wed, 20 Aug 2003 12:51:07 -0700 (PDT) Received: from mail.tcoip.com.br (erato.tco.net.br [200.220.254.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0325343FB1; Wed, 20 Aug 2003 12:51:05 -0700 (PDT) (envelope-from dcs@tcoip.com.br) Received: from tcoip.com.br ([10.0.2.6]) by mail.tcoip.com.br (8.11.6/8.11.6) with ESMTP id h7KJovj01819; Wed, 20 Aug 2003 16:50:57 -0300 Message-ID: <3F43D120.3050905@tcoip.com.br> Date: Wed, 20 Aug 2003 16:50:56 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030702 X-Accept-Language: en-us, en, pt-br, ja MIME-Version: 1.0 To: Julian Elischer References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Sam Leffler cc: freebsd-arch@freebsd.org cc: Lars Eggert cc: Robert Watson cc: freebsd-net@freebsd.org Subject: Re: CFR: bridge locking 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, 20 Aug 2003 19:51:07 -0000 Julian Elischer wrote: > > On Wed, 20 Aug 2003, Robert Watson wrote: > > >>On Wed, 20 Aug 2003, Lars Eggert wrote: >> >> >>>I think you mentioned in the past that NetBSD (OpenBSD?) has bridge code >>>that implements the pseudo-device approach? > > > FreeBSD has both. > If you use netgraph bridging then you are using a more > "link level device" like approach. Nope. Neither netgraph nor bridge(4) produce a pseudo-interface. Unfortunately. It would have solved the problem I was discussing with you (alas, I found a y2k thread, in which Archie and you were also present, about that very same problem). Netgraph's ng_iface is not enough, because it's much more limitted. > > > >>I had an older set of patches (4.x?) that implemented a bridgeX interface >>that saw all of the packets bridged by the bridge. However, it was just a >>pseudo-interface for the purposes of BPF -- it didn't carry a link local >>address, etc. I never tested for interop with IPv6. You can find a very >>old version of this at www.watson.org/~robert/freebsd/bridge.patch. It >>required some cleanup of the interactions between the bridge code and IPFW >>code that have probably since happened in the main tree as well, so the >>chances of this applying or working are effectively 0. :-) >> >>Robert N M Watson FreeBSD Core Team, TrustedBSD Projects >>robert@fledge.watson.org Network Associates Laboratories >> >>_______________________________________________ >>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" >> > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: Daniel.Capo@tco.net.br Daniel.Sobral@tcoip.com.br dcs@tcoip.com.br Outros: dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net The penalty for laughing in a courtroom is six months in jail; if it were not for this penalty, the jury would never hear the evidence. -- H. L. Mencken From owner-freebsd-arch@FreeBSD.ORG Wed Aug 20 12:54:43 2003 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 D76A716A4BF; Wed, 20 Aug 2003 12:54:43 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D54043F93; Wed, 20 Aug 2003 12:54:43 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.8p1/8.12.3) with ESMTP id h7KJsekN072087; Wed, 20 Aug 2003 12:54:40 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h7KJseFs072086; Wed, 20 Aug 2003 12:54:40 -0700 (PDT) (envelope-from rizzo) Date: Wed, 20 Aug 2003 12:54:40 -0700 From: Luigi Rizzo To: "Bruce A. Mah" Message-ID: <20030820125440.A66805@xorpc.icir.org> References: <510776858.1061372094@melange.errno.com> <20030820172342.GA69189@intruder.kitchenlab.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030820172342.GA69189@intruder.kitchenlab.org>; from bmah@freebsd.org on Wed, Aug 20, 2003 at 10:23:42AM -0700 cc: Sam Leffler cc: freebsd-arch@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: CFR: bridge locking 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, 20 Aug 2003 19:54:44 -0000 On Wed, Aug 20, 2003 at 10:23:42AM -0700, Bruce A. Mah wrote: > If memory serves me right, Sam Leffler wrote: > > > One other minor change: I moved the printf "BRIDGE 020214 loaded" under > > bootverbose. Can anyone tell me what 020214 means? yes, it is a timestamp -- just to get an idea on when the code was last touched. cheers luigi > I recently started using bridge(4) functionality and was wondering > about this too. Based on the output of "cvs annotate" and "cvs log", > I concluded that it was a datestamp used by Luigi to keep track of > which version he was working with (on HEAD, this line was last touched > in revision 1.45, which was committed on 15 February 2002). > > Bruce. From owner-freebsd-arch@FreeBSD.ORG Wed Aug 20 12:56:05 2003 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 E5F2A16A4BF; Wed, 20 Aug 2003 12:56:05 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5940443FB1; Wed, 20 Aug 2003 12:56:05 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (rwcrmhc11) with ESMTP id <20030820195545013008ckg2e>; Wed, 20 Aug 2003 19:55:45 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA74663; Wed, 20 Aug 2003 12:55:43 -0700 (PDT) Date: Wed, 20 Aug 2003 12:55:41 -0700 (PDT) From: Julian Elischer To: "Daniel C. Sobral" In-Reply-To: <3F43D120.3050905@tcoip.com.br> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Sam Leffler cc: freebsd-arch@freebsd.org cc: Lars Eggert cc: Robert Watson cc: freebsd-net@freebsd.org Subject: Re: CFR: bridge locking 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, 20 Aug 2003 19:56:06 -0000 On Wed, 20 Aug 2003, Daniel C. Sobral wrote: > Julian Elischer wrote: > > > > On Wed, 20 Aug 2003, Robert Watson wrote: > > > > > >>On Wed, 20 Aug 2003, Lars Eggert wrote: > >> > >> > >>>I think you mentioned in the past that NetBSD (OpenBSD?) has bridge code > >>>that implements the pseudo-device approach? > > > > > > FreeBSD has both. > > If you use netgraph bridging then you are using a more > > "link level device" like approach. > > Nope. Neither netgraph nor bridge(4) produce a pseudo-interface. > Unfortunately. It would have solved the problem I was discussing with > you (alas, I found a y2k thread, in which Archie and you were also > present, about that very same problem). > > Netgraph's ng_iface is not enough, because it's much more limitted. netgraph's eiface node may do better.. > > > > > > > > >>I had an older set of patches (4.x?) that implemented a bridgeX interface > >>that saw all of the packets bridged by the bridge. However, it was just a > >>pseudo-interface for the purposes of BPF -- it didn't carry a link local > >>address, etc. I never tested for interop with IPv6. You can find a very > >>old version of this at www.watson.org/~robert/freebsd/bridge.patch. It > >>required some cleanup of the interactions between the bridge code and IPFW > >>code that have probably since happened in the main tree as well, so the > >>chances of this applying or working are effectively 0. :-) > >> > >>Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > >>robert@fledge.watson.org Network Associates Laboratories > >> > >>_______________________________________________ > >>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" > >> > > > > > > _______________________________________________ > > freebsd-arch@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > > -- > Daniel C. Sobral (8-DCS) > Gerencia de Operacoes > Divisao de Comunicacao de Dados > Coordenacao de Seguranca > VIVO Centro Oeste Norte > Fones: 55-61-313-7654/Cel: 55-61-9618-0904 > E-mail: Daniel.Capo@tco.net.br > Daniel.Sobral@tcoip.com.br > dcs@tcoip.com.br > > Outros: > dcs@newsguy.com > dcs@freebsd.org > capo@notorious.bsdconspiracy.net > > The penalty for laughing in a courtroom is six months in jail; if it > were not for this penalty, the jury would never hear the evidence. > -- H. L. Mencken > > From owner-freebsd-arch@FreeBSD.ORG Wed Aug 20 13:06:39 2003 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 45AB816A4BF; Wed, 20 Aug 2003 13:06:39 -0700 (PDT) Received: from mail.tcoip.com.br (erato.tco.net.br [200.220.254.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E746543FCB; Wed, 20 Aug 2003 13:06:36 -0700 (PDT) (envelope-from dcs@tcoip.com.br) Received: from tcoip.com.br ([10.0.2.6]) by mail.tcoip.com.br (8.11.6/8.11.6) with ESMTP id h7KK6Vj02372; Wed, 20 Aug 2003 17:06:31 -0300 Message-ID: <3F43D4C6.2040705@tcoip.com.br> Date: Wed, 20 Aug 2003 17:06:30 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030702 X-Accept-Language: en-us, en, pt-br, ja MIME-Version: 1.0 To: Julian Elischer References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: CFR: bridge locking 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, 20 Aug 2003 20:06:39 -0000 >>>>On Wed, 20 Aug 2003, Lars Eggert wrote: >>>> >>>>>I think you mentioned in the past that NetBSD (OpenBSD?) has bridge code >>>>>that implements the pseudo-device approach? >>Julian Elischer wrote: >>> >>>FreeBSD has both. >>>If you use netgraph bridging then you are using a more >>>"link level device" like approach. > On Wed, 20 Aug 2003, Daniel C. Sobral wrote: >> >>Nope. Neither netgraph nor bridge(4) produce a pseudo-interface. >>Unfortunately. It would have solved the problem I was discussing with >>you (alas, I found a y2k thread, in which Archie and you were also >>present, about that very same problem). >> >>Netgraph's ng_iface is not enough, because it's much more limitted. Julian Elischer wrote: > > netgraph's eiface node may do better.. ENODOCS. :-) I can barely configure this stuff with the existing docs. Without, I won't even know what hooks there are for it! :-) -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: Daniel.Capo@tco.net.br Daniel.Sobral@tcoip.com.br dcs@tcoip.com.br Outros: dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net ( /\__________/\ ) \(^ @___..___@ ^)/ /\ (\/\/\/\/) /\ / \(/\/\/\/\)/ \ -( """""""""" ) \ _____ / ( /( )\ ) _) (_V) (V_) (_ (V)(V)(V) (V)(V)(V) From owner-freebsd-arch@FreeBSD.ORG Thu Aug 21 09:11:16 2003 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 D1DEF16A4C1 for ; Thu, 21 Aug 2003 09:11:16 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F79043F93 for ; Thu, 21 Aug 2003 09:11:16 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h7LGBEQX007131 for ; Thu, 21 Aug 2003 09:11:14 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h7LGBEKV007130 for arch@freebsd.org; Thu, 21 Aug 2003 09:11:14 -0700 (PDT) Date: Thu, 21 Aug 2003 09:11:14 -0700 From: "David O'Brien" To: arch@freebsd.org Message-ID: <20030821161114.GA7094@dragon.nuxi.com> Mail-Followup-To: David O'Brien , arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.1-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Subject: RCng -- INFO: X depends on Y, which will be forced to start. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: arch@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2003 16:11:17 -0000 What do people think? Can we loose these type of warnings? I'm not sure what their need is. The beauty of RCng is that I can say I want Amd (for example) and not have to think about what else is needed to be started in order for Amd to work. All the info output just obscures the console bootup output and makes us look more Linux-like -- which has a way too noisy bootup for my tastes. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Thu Aug 21 09:40:50 2003 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 3009316A4BF for ; Thu, 21 Aug 2003 09:40:50 -0700 (PDT) Received: from hysteria.spc.org (hysteria.spc.org [195.206.69.234]) by mx1.FreeBSD.org (Postfix) with SMTP id E36A643FE0 for ; Thu, 21 Aug 2003 09:40:48 -0700 (PDT) (envelope-from bms@hysteria.spc.org) Received: (qmail 5993 invoked by uid 5013); 21 Aug 2003 16:37:49 -0000 Date: Thu, 21 Aug 2003 17:37:49 +0100 From: Bruce M Simpson To: David O'Brien , arch@freebsd.org Message-ID: <20030821163749.GC11682@spc.org> References: <20030821161114.GA7094@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030821161114.GA7094@dragon.nuxi.com> User-Agent: Mutt/1.4.1i Organization: SPC Subject: Re: RCng -- INFO: X depends on Y, which will be forced to start. 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: Thu, 21 Aug 2003 16:40:50 -0000 On Thu, Aug 21, 2003 at 09:11:14AM -0700, David O'Brien wrote: > What do people think? Can we loose these type of warnings? I'm not sure > what their need is. The beauty of RCng is that I can say I want Amd (for I agree with you, but perhaps the warnings should be preserved elsewhere? Or toggleable via an rc.conf switch? BMS From owner-freebsd-arch@FreeBSD.ORG Thu Aug 21 09:59:09 2003 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 2B32516A4BF; Thu, 21 Aug 2003 09:59:09 -0700 (PDT) Received: from pool-151-200-10-97.res.east.verizon.net (pool-141-156-222-145.res.east.verizon.net [141.156.222.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8698D43FBF; Thu, 21 Aug 2003 09:59:07 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net (vvja69ogl30bgs5c@localhost [127.0.0.1]) id h7LGx6UT006306; Thu, 21 Aug 2003 12:59:06 -0400 (EDT) (envelope-from mtm@kokeb.ambesa.net) Received: (from mtm@localhost) by kokeb.ambesa.net (8.12.9/8.12.9/Submit) id h7LGx6OV006305; Thu, 21 Aug 2003 12:59:06 -0400 (EDT) (envelope-from mtm) Date: Thu, 21 Aug 2003 12:59:06 -0400 From: Mike Makonnen To: Bruce M Simpson Message-ID: <20030821165906.GB6266@kokeb.ambesa.net> References: <20030821161114.GA7094@dragon.nuxi.com> <20030821163749.GC11682@spc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030821163749.GC11682@spc.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD/5.1-CURRENT (i386) cc: arch@FreeBSD.org cc: David O'Brien Subject: Re: RCng -- INFO: X depends on Y, which will be forced to start. 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: Thu, 21 Aug 2003 16:59:09 -0000 On Thu, Aug 21, 2003 at 05:37:49PM +0100, Bruce M Simpson wrote: > On Thu, Aug 21, 2003 at 09:11:14AM -0700, David O'Brien wrote: > > What do people think? Can we loose these type of warnings? I'm not sure > > what their need is. The beauty of RCng is that I can say I want Amd (for > > > I agree with you, but perhaps the warnings should be preserved elsewhere? > Or toggleable via an rc.conf switch? I already took care of this a couple of days ago. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | Fingerprint: 00E8 61BC 0D75 7FFB E4D3 6BF1 B239 D010 3215 D418 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon ! From owner-freebsd-arch@FreeBSD.ORG Fri Aug 22 09:47:40 2003 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 EF27916A4BF for ; Fri, 22 Aug 2003 09:47:40 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5045243FEA for ; Fri, 22 Aug 2003 09:47:40 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h7MGldQX072207; Fri, 22 Aug 2003 09:47:39 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h7MGlY7w072206; Fri, 22 Aug 2003 09:47:34 -0700 (PDT) Date: Fri, 22 Aug 2003 09:47:34 -0700 From: "David O'Brien" To: Mike Makonnen Message-ID: <20030822164734.GA71360@dragon.nuxi.com> Mail-Followup-To: David O'Brien , Mike Makonnen , Bruce M Simpson , arch@FreeBSD.org References: <20030821161114.GA7094@dragon.nuxi.com> <20030821163749.GC11682@spc.org> <20030821165906.GB6266@kokeb.ambesa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030821165906.GB6266@kokeb.ambesa.net> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.1-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: Bruce M Simpson cc: arch@FreeBSD.org Subject: Re: RCng -- INFO: X depends on Y, which will be forced to start. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2003 16:47:41 -0000 On Thu, Aug 21, 2003 at 12:59:06PM -0400, Mike Makonnen wrote: > On Thu, Aug 21, 2003 at 05:37:49PM +0100, Bruce M Simpson wrote: > > On Thu, Aug 21, 2003 at 09:11:14AM -0700, David O'Brien wrote: > > > What do people think? Can we loose these type of warnings? I'm not sure > > > what their need is. The beauty of RCng is that I can say I want Amd (for > > > > > > I agree with you, but perhaps the warnings should be preserved elsewhere? > > Or toggleable via an rc.conf switch? > > I already took care of this a couple of days ago. thanks! From owner-freebsd-arch@FreeBSD.ORG Sat Aug 23 02:09:25 2003 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 8FF1316A524 for ; Sat, 23 Aug 2003 02:09:24 -0700 (PDT) Received: from HAL9000.homeunix.com (12-233-57-131.client.attbi.com [12.233.57.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 202D944550 for ; Sat, 23 Aug 2003 01:08:50 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.9) with ESMTP id h7N88vtT008113; Sat, 23 Aug 2003 01:08:57 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.9/Submit) id h7N88uDi008112; Sat, 23 Aug 2003 01:08:56 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Sat, 23 Aug 2003 01:08:56 -0700 From: David Schultz To: Nicolas Souchu Message-ID: <20030823080856.GA8081@HAL9000.homeunix.com> Mail-Followup-To: Nicolas Souchu , freebsd-arch@freebsd.org References: <20030816230358.B5747@armor.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030816230358.B5747@armor.free.fr> cc: freebsd-arch@FreeBSD.ORG Subject: Re: Loadable VM pager 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: Sat, 23 Aug 2003 09:09:26 -0000 On Sat, Aug 16, 2003, Nicolas Souchu wrote: > I'm wondering if being able to load dynamically a pager in FreeBSD VM > would be worth and even possible with kobj. Of course that would > introduce some overhead to the page fault handling... Presently, the VM code has a number of special cases based on pager type, and this organization does not lend itself well to object-oriented techniques. At a minimum, those cases would have to be fixed, with consideration to the performance consequences. It's an interesting idea, nonetheless... From owner-freebsd-arch@FreeBSD.ORG Sat Aug 23 07:54:33 2003 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 A539A16A4BF; Sat, 23 Aug 2003 07:54:33 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 619A843FBD; Sat, 23 Aug 2003 07:54:32 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h7NEsIrO086446; Sat, 23 Aug 2003 10:54:18 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)h7NEsIUu086443; Sat, 23 Aug 2003 10:54:18 -0400 (EDT) Date: Sat, 23 Aug 2003 10:54:18 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: David Schultz In-Reply-To: <20030823080856.GA8081@HAL9000.homeunix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Nicolas Souchu cc: freebsd-arch@FreeBSD.ORG Subject: Re: Loadable VM pager 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: Sat, 23 Aug 2003 14:54:33 -0000 On Sat, 23 Aug 2003, David Schultz wrote: > On Sat, Aug 16, 2003, Nicolas Souchu wrote: > > I'm wondering if being able to load dynamically a pager in FreeBSD VM > > would be worth and even possible with kobj. Of course that would > > introduce some overhead to the page fault handling... > > Presently, the VM code has a number of special cases based on pager > type, and this organization does not lend itself well to object-oriented > techniques. At a minimum, those cases would have to be fixed, with > consideration to the performance consequences. It's an interesting > idea, nonetheless... It would be nice if we could easily support research into DSM, etc, using VM pagers. This is one of the research-nice things that we lost in the transition of the code from Mach (or maybe we got the code before Mach was really into that sort of thing, don't know). I agree that one of the key issues will be avoiding slowing the fast path... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories