Date: Thu, 18 Aug 2005 09:55:46 -0700 From: Luigi Rizzo <rizzo@icir.org> To: John Baldwin <jhb@FreeBSD.org> Cc: gnn@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Special schedulers, one CPU only kernel, one only userland Message-ID: <20050818095546.A91965@xorpc.icir.org> In-Reply-To: <200508181023.05929.jhb@FreeBSD.org>; from jhb@FreeBSD.org on Thu, Aug 18, 2005 at 10:23:04AM -0400 References: <42F9ECF2.8080809@freebsd.org> <200508171328.29654.jhb@FreeBSD.org> <20050817184056.A72643@xorpc.icir.org> <200508181023.05929.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050818095546.A91965>