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

[John Baldwin]

On 30-Apr-2003 M. Warner Losh wrote:
> In message: <20030430093448.U31027 at beagle.fokus.fraunhofer.de>
>             Harti Brandt <brandt at 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.

This is why I think driver locks should be added last after the
infrastructure is finished.

-- 

John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/