Special schedulers, one CPU only kernel, one only userland
jhb at FreeBSD.org
Thu Aug 18 16:28:27 GMT 2005
On Wednesday 17 August 2005 09:40 pm, Luigi Rizzo wrote:
> On Wed, Aug 17, 2005 at 01:28:28PM -0400, John Baldwin wrote:
> > fxp(4)'s locking is somewhat buggy where you are looking probably. I
> > think I've already committed the fixes to HEAD so that detach() is less
> > discouraging (we just lock fxp_stop() in detach now). The calls to
> well, my specific concern with the detach routine (but I was wrong,
> at least on this part) was that dropping the lock could cause the struct to
> go away while the interrupt handler was working on it.
> Now i see that this should be safe because bus_teardown_intr()
> blocks until we are out of the handler (the comment "Unhook interrupt
> before dropping lock." is probably stale...), and given that
> the detach() handler runs under giant and we cannot have multiple
> instances of it, at least this path seems safe.
> However I am still unclear on what happens if a detach() is racing with the
> output path (leading to fxp_start()).
Note that we first down the interface via fxp_stop() and then we unhook it
from the network stack using ether_ifdetach(). Once we've done
ether_ifdetach() the network stack can't get to the fxp device anymore.
John Baldwin <jhb at FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
More information about the freebsd-arch