Special schedulers, one CPU only kernel, one only userland

Luigi Rizzo rizzo at icir.org
Thu Aug 18 16:55:47 GMT 2005


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...

	cheers
	luigi


More information about the freebsd-arch mailing list