Special schedulers, one CPU only kernel, one only userland

[John Baldwin]

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