From owner-freebsd-net@FreeBSD.ORG Tue May 31 23:48:17 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 2406F16A41C; Tue, 31 May 2005 23:48:17 +0000 (GMT) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.3/8.13.1) with ESMTP id j4VNmGok021529; Tue, 31 May 2005 19:48:16 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.3/8.13.1/Submit) id j4VNmG5V021528; Tue, 31 May 2005 19:48:16 -0400 (EDT) (envelope-from green) Date: Tue, 31 May 2005 19:48:16 -0400 From: Brian Fundakowski Feldman To: Andrew Thompson Message-ID: <20050531234816.GA975@green.homeunix.org> References: <20050530232554.GA8674@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050530232554.GA8674@heff.fud.org.nz> User-Agent: Mutt/1.5.6i Cc: pf@freebsd.org, hackers@freebsd.org, net@freebsd.org Subject: Re: RFC: if_bridge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 23:48:17 -0000 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. \,,,,,,,,,,,,,,,,,,,,,,\