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