Date: Thu, 18 Aug 2005 13:12:20 -0400 From: John Baldwin <jhb@FreeBSD.org> To: Luigi Rizzo <rizzo@icir.org> Cc: gnn@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Special schedulers, one CPU only kernel, one only userland Message-ID: <200508181312.21512.jhb@FreeBSD.org> In-Reply-To: <20050818095546.A91965@xorpc.icir.org> References: <42F9ECF2.8080809@freebsd.org> <200508181023.05929.jhb@FreeBSD.org> <20050818095546.A91965@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200508181312.21512.jhb>