From owner-cvs-all@FreeBSD.ORG Mon May 5 01:30:20 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 7671437B401; Mon, 5 May 2003 01:30:20 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5539043F85; Mon, 5 May 2003 01:30:18 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h458UFE03429; Mon, 5 May 2003 10:30:15 +0200 (MEST) Date: Mon, 5 May 2003 10:30:15 +0200 (CEST) From: Harti Brandt To: John Baldwin In-Reply-To: Message-ID: <20030505102728.F53365@beagle.fokus.fraunhofer.de> References: 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: "M. Warner Losh" 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: Mon, 05 May 2003 08:30:20 -0000 On Wed, 30 Apr 2003, John Baldwin wrote: JB> JB>On 30-Apr-2003 M. Warner Losh wrote: JB>> In message: <20030430093448.U31027@beagle.fokus.fraunhofer.de> JB>> Harti Brandt writes: JB>>: On Tue, 29 Apr 2003, Nate Lawson wrote: JB>>: JB>>: NL>On Mon, 28 Apr 2003, Warner Losh wrote: JB>>: JB>>: NL>> 2) Call FXP_UNLOCK() before calling bus_teardown_intr to avoid JB>>: NL>> a possible deadlock reported by jhb. JB>>: NL> JB>>: NL>This adds a race since fxp_intr could occur after the unlock but before JB>>: NL>the bus_teardown_intr call. The reason why I tore down the intr while JB>>: NL>holding the lock is so fxp_intr would be prevented from accessing the JB>>: NL>device until it has been disabled. Then the normal checks in fxp_intr JB>>: NL>(IFF_OACTIVE or whatever) would show the card is gone and return without JB>>: NL>accessing it. I guess this is ok since ether_ifdetach is still called JB>>: NL>with the lock held (since it is what clears IFF_OACTIVE) but I'm JB>>: NL>interested in your thoughts. JB>>: JB>>: For what I know, you should not call ether_ifdetach with the card lock JB>>: held. ether_ifdetach calls if_detach which in turn may lock the radix node JB>>: head to remove routes. The lock order should be 1) radix node head, 2) JB>>: interface not the other way around. JB>> JB>> Right now there's no safe way to use driver locks. Sometimes, we have JB>> to acquire the locks NET, DRIVER. Other times you do the reverse. JB>> There are other times you do need to call ether_ifdetach with the lock JB>> held. This is a real mess. I'm contemplating a strawman proposal to JB>> help address these issues. JB> JB>This is why I think driver locks should be added last after the JB>infrastructure is finished. It's just easier to structure the code for correct locking while you're writing it than a couple of years later. But, yes, we should try to get a proposal for the infrastructure. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org