Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 6 Jan 2003 23:30:10 +0900
From:      Kyunghwan Kim <redjade@ada.snu.ac.kr>
To:        Harti Brandt <brandt@fokus.gmd.de>
Cc:        Nate Lawson <nate@root.org>, current@FreeBSD.ORG, net@FreeBSD.ORG
Subject:   Re: Proper -current if_attach locking?
Message-ID:  <20030106143010.GA11655@ada.snu.ac.kr>
In-Reply-To: <20030106105529.C12568-100000@beagle.fokus.gmd.de>
References:  <Pine.BSF.4.21.0301031458210.99923-100000@root.org> <20030106105529.C12568-100000@beagle.fokus.gmd.de>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

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).
Maybe these locks should be adaptive or spin....
And IFNET_*LOCK() should remain for adding/removing ifnet struct to
the global ifnet whose type is ifnethead.

In case of ifqueue, it should not need to acquire its ifnet lock
because ifqueue has its own mutex.
-- 
Kyunghwan Kim
redjade@ada.snu.ac.kr

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030106143010.GA11655>