panic in rt_check_fib()
Giorgos Keramidas
keramida at freebsd.org
Mon Sep 15 02:54:47 UTC 2008
On Sun, 14 Sep 2008 12:13:42 -0700, Julian Elischer <julian at elischer.org> wrote:
> Giorgos Keramidas wrote:
>> Now an interesting question is: Is it `normal' that the USED rtentry
>> objects keep going up at every interface restart and are (at least at
>> first glance) not reclaimed as fast as they are acquired?
>
> does it happen with the old rt_check in the case where it doesn't crash?
Hi Julian,
Yes it happens with the old kernel too. I tried bringing the re0
interface up and down with a kernel compiled from a clean copy of
base/head @ 182948. The rtentry's allocated seem to be going linearly
up every time I restart the interface with the old, unpatched
rt_check_fib() too.
So if there is an rtentry leak, it exists in both the unpatched and the
patched kernels.
By going through the last rt_check_fib() you sent, I don't see an
obvious place where the leak could occur in *this* function, so I will
try to see if it's easier to find out where rtentry's are pulled from
the related zone. Then by correlating these with the places where
rtentry's are freed it may become more obvious why/when the USED objects
get bumped.
It may be just a missing RT_REMREF() elsewhere, but I can't tell for
sure yet where/when this happens... I'll keep looking.
In the meantime, the new rt_check_fib() has saved me from several
semi-random panics a week, so I think I like it :-D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20080915/c9eeb121/attachment.pgp
More information about the freebsd-current
mailing list