Date: Mon, 5 May 2003 10:30:15 +0200 (CEST) From: Harti Brandt <brandt@fokus.fraunhofer.de> To: John Baldwin <jhb@FreeBSD.org> Cc: nate@root.org Subject: Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h Message-ID: <20030505102728.F53365@beagle.fokus.fraunhofer.de> In-Reply-To: <XFMail.20030430135239.jhb@FreeBSD.org> References: <XFMail.20030430135239.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <brandt@fokus.fraunhofer.de> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030505102728.F53365>