Date: Mon, 3 Jul 2006 13:28:03 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: Robert Watson <rwatson@FreeBSD.org> Cc: Yar Tikhiy <yar@comp.chem.msu.su>, src-committers@FreeBSD.org, Julian Elischer <julian@elischer.org>, FreeBSD Net <freebsd-net@FreeBSD.org> Subject: Re: cvs commit: src/sys/net if_vlan.c Message-ID: <20060703202803.GA22556@odin.ac.hmc.edu> In-Reply-To: <20060630115749.G3964@fledge.watson.org> References: <200606290752.k5T7qU06021639@repoman.freebsd.org> <20060629132354.D73145@mp2.macomnet.net> <20060629131201.GA67682@comp.chem.msu.su> <44A40C25.904@elischer.org> <20060630115749.G3964@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 30, 2006 at 12:01:23PM +0100, Robert Watson wrote: >=20 > On Thu, 29 Jun 2006, Julian Elischer wrote: >=20 > >>I stress tested gif(4) in the same manner for kicks and got a very=20 > >>similar panic in in_control(). I suppose that my change eliminated a= =20 > >>concurrency problem in vlan(4) and we began to feel the lack of=20 > >>refcounting at ifnet level. Indeed, a thread can keep a pointer to an= =20 > >>ifnet beyond its lifetime and panic the system on access to the dead=20 > >>ifnet. > > > >Unfortunatly, since mbufs point to ifnets it is almost impossible to=20 > >"efficiently" refcount ifnets. Mbufs may persist almost indefinitly in = a=20 > >socket receive buffer, well after the given receive interface has gone= =20 > >away. I submitted patches to full real referenc counting of ifnets in 19= 95=20 > >but it was already too cumbersom then, and since then it has gotten wors= e.=20 > >(due to SMP etc.) >=20 > Partial solutions are possible here -- even if we don't immediately fix t= he=20 > mbuf pointer issue, we can fix other types of ifnet references to be real= ,=20 > such as references from heavier weight administrative structures and=20 > operations, even if mbufs don't get them. It's been suggested that=20 > interfaces become dead and be GC'd after a timeout in order to reduce the= =20 > chances of mbuf related races. I think this is a pretty reasonable=20 > work-around to the general problem here, especially if "dead" is really= =20 > implemented properly. An example of a "bad" implementation of dead would= =20 > have the ifnet continue to be visible and occupy space in the interface= =20 > name space, preventing tun0 from being immediately reallocated after it i= s=20 > destroyed. A better implementation would have all external signs of the= =20 > ifnet disappear, except that the pointer remains minimally valid for a fe= w=20 > seconds. Not ideal, but better than reference counting ifnets from mbufs= . =20 > For gif interfaces, etc, real references are possible and desirable. The goal of the work to remove the ifnet from the softc was that we would end up in a situation where if_free (or if_detach if we remove if_free) would cause the interface to have all it's state set to safe but dead values and remove it from the ifnet list. At that point access by pointer or index would still work, but ifconfig wouldn't see it since it would not be on the ifnet list and syscalls, sysctl, or ioctls that access interfaces by would be modified to detect the dead state and act as though the interface is not there. We could then consider either holding the interface for a configurable or computed length of time or adding some sort of refcounting (probably impractical). In practice ifnet and indexes are pretty cheap so holding on to an interface for up to a couple minutes should be OK in most cases. For some applications (really massive tunnel brokers) it might be beneficial to change if_index from a u_short to an int to increase the available set. I'd been meaning to work on this, but real life has interfered. -- 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 --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFEqX3SXY6L6fI4GtQRAqy9AKDDQmK7nb+MZayhJ6qSDISpzhPm0gCfYQyq cpTTgo83IAemoaEu2z5mS88= =+pdk -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060703202803.GA22556>