RFC: if_bridge
Brian Fundakowski Feldman
green at freebsd.org
Tue May 31 17:18:34 PDT 2005
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 at FreeBSD.org \ The Power to Serve! \
Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
More information about the freebsd-pf
mailing list