From owner-cvs-all@FreeBSD.ORG Wed Apr 30 08:14:43 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E33937B401; Wed, 30 Apr 2003 08:14:43 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4960343F3F; Wed, 30 Apr 2003 08:14:42 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h3UFEZA7097726; Wed, 30 Apr 2003 09:14:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 30 Apr 2003 09:14:21 -0600 (MDT) Message-Id: <20030430.091421.81670921.imp@bsdimp.com> To: brandt@fokus.fraunhofer.de From: "M. Warner Losh" In-Reply-To: <20030430093448.U31027@beagle.fokus.fraunhofer.de> References: <20030430093448.U31027@beagle.fokus.fraunhofer.de> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: nate@root.org Subject: Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2003 15:14:43 -0000 In message: <20030430093448.U31027@beagle.fokus.fraunhofer.de> Harti Brandt writes: : On Tue, 29 Apr 2003, Nate Lawson wrote: : : NL>On Mon, 28 Apr 2003, Warner Losh wrote: : : NL>> 2) Call FXP_UNLOCK() before calling bus_teardown_intr to avoid : NL>> a possible deadlock reported by jhb. : NL> : NL>This adds a race since fxp_intr could occur after the unlock but before : NL>the bus_teardown_intr call. The reason why I tore down the intr while : NL>holding the lock is so fxp_intr would be prevented from accessing the : NL>device until it has been disabled. Then the normal checks in fxp_intr : NL>(IFF_OACTIVE or whatever) would show the card is gone and return without : NL>accessing it. I guess this is ok since ether_ifdetach is still called : NL>with the lock held (since it is what clears IFF_OACTIVE) but I'm : NL>interested in your thoughts. : : For what I know, you should not call ether_ifdetach with the card lock : held. ether_ifdetach calls if_detach which in turn may lock the radix node : head to remove routes. The lock order should be 1) radix node head, 2) : interface not the other way around. Right now there's no safe way to use driver locks. Sometimes, we have to acquire the locks NET, DRIVER. Other times you do the reverse. There are other times you do need to call ether_ifdetach with the lock held. This is a real mess. I'm contemplating a strawman proposal to help address these issues. Warner