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

[Harti Brandt]

On Wed, 30 Apr 2003, John Baldwin wrote:

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