From owner-cvs-src@FreeBSD.ORG Mon May 5 03:24:12 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6972E37B401; Mon, 5 May 2003 03:24:12 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72DF243FB1; Mon, 5 May 2003 03:24:10 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h45AO4E16888; Mon, 5 May 2003 12:24:05 +0200 (MEST) Date: Mon, 5 May 2003 12:24:04 +0200 (CEST) From: Harti Brandt To: "M. Warner Losh" In-Reply-To: <20030430.091421.81670921.imp@bsdimp.com> Message-ID: <20030505122236.G53365@beagle.fokus.fraunhofer.de> References: <20030430.091421.81670921.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2003 10:24:12 -0000 On Wed, 30 Apr 2003, M. Warner Losh wrote: MWL>In message: <20030430093448.U31027@beagle.fokus.fraunhofer.de> MWL> Harti Brandt writes: MWL>: On Tue, 29 Apr 2003, Nate Lawson wrote: MWL>: MWL>: NL>On Mon, 28 Apr 2003, Warner Losh wrote: MWL>: MWL>: NL>> 2) Call FXP_UNLOCK() before calling bus_teardown_intr to avoid MWL>: NL>> a possible deadlock reported by jhb. MWL>: NL> MWL>: NL>This adds a race since fxp_intr could occur after the unlock but before MWL>: NL>the bus_teardown_intr call. The reason why I tore down the intr while MWL>: NL>holding the lock is so fxp_intr would be prevented from accessing the MWL>: NL>device until it has been disabled. Then the normal checks in fxp_intr MWL>: NL>(IFF_OACTIVE or whatever) would show the card is gone and return without MWL>: NL>accessing it. I guess this is ok since ether_ifdetach is still called MWL>: NL>with the lock held (since it is what clears IFF_OACTIVE) but I'm MWL>: NL>interested in your thoughts. MWL>: MWL>: For what I know, you should not call ether_ifdetach with the card lock MWL>: held. ether_ifdetach calls if_detach which in turn may lock the radix node MWL>: head to remove routes. The lock order should be 1) radix node head, 2) MWL>: interface not the other way around. MWL> MWL>Right now there's no safe way to use driver locks. Sometimes, we have MWL>to acquire the locks NET, DRIVER. Other times you do the reverse. MWL>There are other times you do need to call ether_ifdetach with the lock MWL>held. This is a real mess. I'm contemplating a strawman proposal to MWL>help address these issues. I'd love to see it. But, what's the point in this iterations over fxp if they are deliberatly wrong? Others will copy this locking stategy to their drivers. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org