Date: Tue, 31 May 2005 19:48:16 -0400 From: Brian Fundakowski Feldman <green@freebsd.org> To: Andrew Thompson <thompsa@freebsd.org> Cc: pf@freebsd.org, hackers@freebsd.org, net@freebsd.org Subject: Re: RFC: if_bridge Message-ID: <20050531234816.GA975@green.homeunix.org> In-Reply-To: <20050530232554.GA8674@heff.fud.org.nz> References: <20050530232554.GA8674@heff.fud.org.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 31, 2005 at 11:25:54AM +1200, Andrew Thompson wrote: > Hi, > > I am looking for testers and code review for if_bridge, the bridge > implementation from NetBSD (and OpenBSD). > > The patch and instructions can be found at: > > http://people.freebsd.org/~thompsa/ > > Highlights include: > - 802.1d spanning tree support > - management of the bridge MAC table > - view bridged packets with bpf(4) > - good firewall support > > > I am especially interested in people who can test !i386, and users with > existing STP networks. I am looking forward to getting your feedback! As you know, I've been testing this on 5.4 in a transparent ipfw/ALTQ bridging/traffic-shaping-firewall setup. I ran into quite a few more issues with the driver's usage of locking while determining the proper configuration (which, btw, is to assign no layer 3 addresses to the internal or external interfaces, but assign them to the bridge interface). Some of these have since been fixed by you or I, but the most serious is the deadlock caused by not having consistency in data access between the input/output interfaces attached to the bridge and the bridge interface itself. It was quite simple to reproduce using IPFW dynamic rules and two fxp(4). The situation that occurs is the input path having locked the bridge, then the interface, and the output path locking the real interface and then trying to lock the bridge. It can be fixed by deferring the if_start(9), but having not run it with WITNESS I'm not certain that is the only big problem. Ideally, there should be a global bridge-list shared/exclusive lock and per-bridge shared/exclusive locks. This will require a fair bit of code churn... but the current state is largely not productionable on FreeBSD thanks to a locking versus IPL model being used in the kernel versus the if_bridge(4) code having been structured for IPL. I very much like this far more featureful and cleaner bridging implementation; it would benefit from implementing a locking strategy almost entirely not unlike Netgraph. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050531234816.GA975>