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