From owner-freebsd-current Mon Jan 6 17:12:27 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3544137B401 for ; Mon, 6 Jan 2003 17:12:26 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 58FE843EA9 for ; Mon, 6 Jan 2003 17:12:25 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 12649 invoked by uid 1000); 7 Jan 2003 01:12:26 -0000 Date: Mon, 6 Jan 2003 17:12:26 -0800 (PST) From: Nate Lawson To: Maxime Henrion Cc: current@freebsd.org Subject: Re: if_dc.c locking patch In-Reply-To: <20030107010405.GB66404@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@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, Maxime Henrion wrote: > Nate Lawson wrote: > > Attached is a diff that fixes a "could sleep" problem where > > ether_ifattach() does a malloc and dc(4) is holding a lock in its softc. > > It uses a cleaner exit strategy with only one call to DC_UNLOCK and no > > multiple return statements as well as fixing one place where "error" > > wasn't set. If people are ok with it, I'll sweep other drivers that have > > a similar problem. > > Doing this would maybe be a bit premature. A lot of drivers have > FOO_LOCK and FOO_UNLOCK macros set to nothing, because of similar > problems you're trying to fix. Interface locking probably needs to be > rethought. I appreciate the insight but this seems pretty straightforward -- if a driver needs to muck with registers, it should use a per-device lock. If it needs to change global state (i.e. ether_ifattach), it's up to the called subsystem to do its own locking. The two are orthogonal. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message