Special schedulers, one CPU only kernel, one only userland

[John Baldwin]

On Thursday 18 August 2005 12:55 pm, Luigi Rizzo wrote:
> On Thu, Aug 18, 2005 at 10:23:04AM -0400, John Baldwin wrote:
> ...
>
> > > 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.
>
> It might have gotten there before, then this sequence might occur:
>
> 	thread 'fxp_detach'	thread 'fxp_start'
>
> 	acquire fxp lock	wait for lock (goes to sleep maybe ?)
> 	fxp_stop
> 	release fxp lock
> 	destroy everything
> 	including the lock
> 				resume, mtx_lock -> boom
>
> hmmm... it's really tricky to follow. Maybe this does not happen,
> but i wouldn't know why as fxp_detach() is under giant but the
> path leading to fxp_start is not...

ether_ifdetach() should be handling this for us I think by blocking until any 
known top-half threads are out of the driver.  It may not be doing that yet, 
but I think that is where it should happen similar to how we use 
bus_teardown_intr() and callout_drain() in detach to block until other 
threads are out of our driver if necessary.

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