From owner-freebsd-net@FreeBSD.ORG Tue May 31 23:58:51 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7093716A41C; Tue, 31 May 2005 23:58:51 +0000 (GMT) (envelope-from thompsa@fud.org.nz) Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id E173E43D1D; Tue, 31 May 2005 23:58:50 +0000 (GMT) (envelope-from thompsa@fud.org.nz) Received: from thompsa by heff.fud.org.nz with local (Exim 4.50 (FreeBSD)) id 1DdGdF-0003VG-MF; Wed, 01 Jun 2005 11:58:49 +1200 Date: Wed, 1 Jun 2005 11:58:49 +1200 From: Andrew Thompson To: Brian Fundakowski Feldman Message-ID: <20050531235849.GA13258@heff.fud.org.nz> References: <20050530232554.GA8674@heff.fud.org.nz> <20050531234816.GA975@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050531234816.GA975@green.homeunix.org> User-Agent: Mutt/1.4.2.1i Sender: Andrew Thompson 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:58:51 -0000 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? cheers, Andrew