From owner-p4-projects@FreeBSD.ORG Sun Jan 14 02:25:39 2007 Return-Path: X-Original-To: p4-projects@freebsd.org Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 29D1916A415; Sun, 14 Jan 2007 02:25:39 +0000 (UTC) X-Original-To: perforce@freebsd.org Delivered-To: perforce@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D10A316A40F for ; Sun, 14 Jan 2007 02:25:38 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe09.swip.net [212.247.155.1]) by mx1.freebsd.org (Postfix) with ESMTP id 6CE0D13C441 for ; Sun, 14 Jan 2007 02:25:38 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [193.217.102.48] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe09.swip.net (CommuniGate Pro SMTP 5.0.12) with ESMTPA id 213159075; Sun, 14 Jan 2007 02:25:31 +0100 From: Hans Petter Selasky To: "M. Warner Losh" Date: Sun, 14 Jan 2007 02:25:04 +0100 User-Agent: KMail/1.7 References: <200701122132.l0CLWuAG096027@repoman.freebsd.org> <20070113.122940.420518338.imp@bsdimp.com> In-Reply-To: <20070113.122940.420518338.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701140225.05299.hselasky@c2i.net> Cc: perforce@freebsd.org Subject: Re: PERFORCE change 112835 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2007 02:25:39 -0000 On Saturday 13 January 2007 20:29, M. Warner Losh wrote: > In message: <200701122132.l0CLWuAG096027@repoman.freebsd.org> > > Hans Petter Selasky writes: > : http://perforce.freebsd.org/chv.cgi?CH=112835 > : > : Change 112835 by hselasky@hselasky_mini_itx on 2007/01/12 21:32:24 > : > : ether_ifattach() must be called without any mutexes held, hence > : it can sleep. Use generated typedef's for prototypes for exported > : device methods. This prevents invalid parameter passing and return. > > Why do the attach methods even have locked mutexes to drop? That was > a common error in the early locking efforts that too many network > drivers inherited. Maybe the right fix is to just remove the > lock/unlock pairs in attach entirely... > The attach code in question is run from a separate config thread, which by default locks "sc->sc_mtx" before calling the callback function. Therefore the code unlocks that lock, to avoid sleeping with mutex locked errors. Probably all of the attach code can run without "sc->sc_mtx" locked, but will require Giant locked, when changing the device tree, for example when adding new child devices like MII-bus instances. --HPS