Date: Wed, 17 Aug 2005 18:40:56 -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: <20050817184056.A72643@xorpc.icir.org> In-Reply-To: <200508171328.29654.jhb@FreeBSD.org>; from jhb@FreeBSD.org on Wed, Aug 17, 2005 at 01:28:28PM -0400 References: <42F9ECF2.8080809@freebsd.org> <200508170836.05861.jhb@FreeBSD.org> <20050817093332.A85431@xorpc.icir.org> <200508171328.29654.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Aug 17, 2005 at 01:28:28PM -0400, John Baldwin wrote: ... > fxp(4)'s locking is somewhat buggy where you are looking probably. I think > I've already committed the fixes to HEAD so that detach() is less > discouraging (we just lock fxp_stop() in detach now). The calls to well, my specific concern with the detach routine (but I was wrong, at least on this part) was that dropping the lock could cause the struct to go away while the interrupt handler was working on it. Now i see that this should be safe because bus_teardown_intr() blocks until we are out of the handler (the comment "Unhook interrupt before dropping lock." is probably stale...), and given that the detach() handler runs under giant and we cannot have multiple instances of it, at least this path seems safe. However I am still unclear on what happens if a detach() is racing with the output path (leading to fxp_start()). cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050817184056.A72643>