cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h

[Harti Brandt]

On Wed, 30 Apr 2003, M. Warner Losh wrote:

MWL>In message: <20030430093448.U31027 at beagle.fokus.fraunhofer.de>
MWL>            Harti Brandt <brandt at 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 at fokus.fraunhofer.de, harti at freebsd.org