Date: Thu, 18 Aug 2005 12:06:25 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-arch@freebsd.org, gnn@freebsd.org Subject: Re: Special schedulers, one CPU only kernel, one only userland Message-ID: <20050818190625.GA28174@odin.ac.hmc.edu> In-Reply-To: <200508181312.21512.jhb@FreeBSD.org> References: <42F9ECF2.8080809@freebsd.org> <200508181023.05929.jhb@FreeBSD.org> <20050818095546.A91965@xorpc.icir.org> <200508181312.21512.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 18, 2005 at 01:12:20PM -0400, John Baldwin wrote: > 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 unho= ok > > > it from the network stack using ether_ifdetach(). Once we've done > > > ether_ifdetach() the network stack can't get to the fxp device anymor= e. > > > > 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... >=20 > ether_ifdetach() should be handling this for us I think by blocking until= any=20 > known top-half threads are out of the driver. It may not be doing that y= et,=20 > but I think that is where it should happen similar to how we use=20 > bus_teardown_intr() and callout_drain() in detach to block until other=20 > threads are out of our driver if necessary. Certainly we need assurance that nothing is going to try and touch the driver before the driver's detach function calls if_free. After if_free returns, no aspect of the driver should touch the ifnet. Other parts of the networking system might still have refrence to it should we end up with a refcouting scheme where the final free of ifnets comes some time later. All refrences to the softc need to be pruged prior to exit from the detach routine. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDBNwxXY6L6fI4GtQRAs2sAJ9rLUPGQkiobEFTsp2Gvf9XieaJUwCeKkzE Yf9KkU4AyKtpO+if6CygOTs= =our9 -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050818190625.GA28174>