Date: Tue, 31 May 2005 20:18:33 -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: <20050601001833.GB975@green.homeunix.org> In-Reply-To: <20050531235849.GA13258@heff.fud.org.nz> References: <20050530232554.GA8674@heff.fud.org.nz> <20050531234816.GA975@green.homeunix.org> <20050531235849.GA13258@heff.fud.org.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 01, 2005 at 11:58:49AM +1200, Andrew Thompson wrote: > On Tue, May 31, 2005 at 07:48:16PM -0400, Brian Fundakowski Feldman wrote: > > 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/ > > > > > > > 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. > > > > Have you looked at the patch above, I have been using bridge-list and > per-bridge locks for about a week now. There have been a couple of > changes from the original patch you have, are you able to re-test? I only skimmed it enough to see you had fixed one of the issues (bridge_rtable_fini() asserting a lock it did not own) but not the issue where you simply cannot call or be called from both directions with regard to a bridged interface. Unfortunately, I don't think there's a 100% reliable way to defer if_start() calls :-/ -- 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?20050601001833.GB975>