In article <[EMAIL PROTECTED]>,
Garrett Wollman <[EMAIL PROTECTED]> wrote:
> <<On Fri, 26 Nov 1999 17:41:49 -0800 (PST), John Polstra <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
