From owner-freebsd-current Tue Nov 30 17:41:54 1999 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 5DB6414CAF for ; Tue, 30 Nov 1999 17:41:50 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id RAA07933; Tue, 30 Nov 1999 17:41:49 -0800 (PST) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id RAA08633; Tue, 30 Nov 1999 17:41:48 -0800 (PST) (envelope-from jdp@polstra.com) Date: Tue, 30 Nov 1999 17:41:48 -0800 (PST) Message-Id: <199912010141.RAA08633@vashon.polstra.com> To: wollman@khavrinen.lcs.mit.edu Subject: Re: Route table leaks 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> Organization: Polstra & Co., Seattle, WA Cc: current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <199911291806.NAA35374@khavrinen.lcs.mit.edu>, Garrett Wollman wrote: > < 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