From owner-freebsd-net Mon Jan 6 16:26:17 2003 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 CCA5537B401 for ; Mon, 6 Jan 2003 16:26:15 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 0728543EC5 for ; Mon, 6 Jan 2003 16:26:11 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 12467 invoked by uid 1000); 7 Jan 2003 00:26:11 -0000 Date: Mon, 6 Jan 2003 16:26:11 -0800 (PST) From: Nate Lawson To: Kyunghwan Kim Cc: current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: Proper -current if_attach locking? In-Reply-To: <20030106143010.GA11655@ada.snu.ac.kr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 6 Jan 2003, Kyunghwan Kim wrote: > On Mon, Jan 06, 2003 at 10:58:25AM +0100, Harti Brandt wrote: > > On Fri, 3 Jan 2003, Nate Lawson wrote: > > NL>I was looking into some "could sleep messages" and found some bogus > > NL>locking in the attach routine of many drivers. Several init a mtx in > > NL>their softc and then lock/unlock it in their attach routine. This, of > > NL>course, does nothing to provide exclusive access to a device. I assume > > NL>there is going to be a global IF_LOCK or something to be used in attach > > NL>routines. Can someone fill me in on the intended design? > > > > Probably not. I asked the same question a couple of month ago and got 0 > > answers. I think, there is no way, the driver itself can assure exclusive > > access to the device it is attaching. It *must* assume, that there is some > > kind of locking around the call to the attach routine. Getting the lock in > > the softc inside the attach routine may be neccessary, because the routine > > may call other functions that assume they have the lock. > > Only using lock in softc can't assure its exclusive access > because there are some cases of changing some values in ifnet struct > outside of device driver routines. > > Most of the NIC drivers don't have its own locks for now, and using > both IFNET_*LOCK() and its own softc lock can't make everything in sync. My point. > There should be two use of locks IMO: one or more per-device locks > in driver softc for manipulating per-device private data protection, > and ifnet lock for each ifnet struct protection (such as ifnet.if_mtx). Looking further into sys/net/if.c, it appears that the list of interfaces is protected by IFNET_WLOCK in if_attach(). I think it's safe to work under the following assumptions: 1. newbus will not call an attach routine twice for the same hw 2. ifnet routines take care of themselves 3. per-device locking is only necessary to provide exclusive access within a given driver instance. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message