Date: Mon, 5 May 2003 12:24:04 +0200 (CEST) From: Harti Brandt <brandt@fokus.fraunhofer.de> To: "M. Warner Losh" <imp@bsdimp.com> Cc: nate@root.org Subject: Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h Message-ID: <20030505122236.G53365@beagle.fokus.fraunhofer.de> In-Reply-To: <20030430.091421.81670921.imp@bsdimp.com> References: <Pine.BSF.4.21.0304291101001.75697-100000@root.org> <20030430.091421.81670921.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 30 Apr 2003, M. Warner Losh wrote: MWL>In message: <20030430093448.U31027@beagle.fokus.fraunhofer.de> MWL> Harti Brandt <brandt@fokus.fraunhofer.de> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030505122236.G53365>