Date: Tue, 30 Nov 1999 17:41:48 -0800 (PST) From: John Polstra <jdp@polstra.com> To: wollman@khavrinen.lcs.mit.edu Cc: current@freebsd.org Subject: Re: Route table leaks Message-ID: <199912010141.RAA08633@vashon.polstra.com> In-Reply-To: <199911291806.NAA35374@khavrinen.lcs.mit.edu> References: <199911220150.UAA78559@khavrinen.lcs.mit.edu> <199911221552.KAA84691@khavrinen.lcs.mit.edu> <199911270141.RAA29416@vashon.polstra.com> <199911291806.NAA35374@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <199911291806.NAA35374@khavrinen.lcs.mit.edu>, Garrett Wollman <wollman@khavrinen.lcs.mit.edu> wrote: > <<On Fri, 26 Nov 1999 17:41:49 -0800 (PST), John Polstra <jdp@polstra.com> said: > > > The route disappears from the routing table, but it is > > not freed. (The Leak.) > > Actually, no. > > > Now cause some packets to travel on the connection. A new cloned > > route is created and added to the routing table. > > Here is where the leak happens, as demonstrated by your patch. By "The Leak" I meant the moment when a routing table entry becomes unreferenced without being freed. But it's not worth arguing about. > (Great detective work, BTW.) Thanks! I definitely learned a lot about the routing code. :-) > > 1. Do I really need the splnet calls around RTFREE? > > I don't think so. All calls into the routing code should already be > protected by splnet. Good -- that's what I was hoping you'd say. I'll go over all the calls, and if I'm reasonably convinced that they're already at splnet then I'll test it for awhile without the hopefully-redundant splnet calls. I ran it that way here at home on a very lightly loaded system for a day or so without problems. But that doesn't prove much. > We may have to revisit this in the future for finer-grained locking. Good point. > > 2. To eliminate all the duplicated code, shall I make rtalloc just > > call rtalloc_ign(ro, 0UL)? I assume that was avoided originally for > > performance reasons, but now there's more code than before. > > Actually, it was avoided originally because it was easier to just cut > and paste. There is no inherent reason for the duplication, although > Matt's suggestion of topologically sorting the routines so that GCC > will have a chance at inlining is not a bad one. Thanks, that makes me feel better. > (I'd actually like to find all the calls to rtalloc() and simply add > an extra argument to them. I can't fathom why I didn't do that five > years ago....) I'm just wondering how much of a "standard" kernel API rtalloc() is. I.e., might 3rd-party drivers call it? The only one I have a copy of is the driver from ET Inc., and it doesn't call any of the routing functions. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "No matter how cynical I get, I just can't keep up." -- Nora Ephron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912010141.RAA08633>