Thread (9 messages) flat view 9 messages, 3 authors, 2012-11-15

Re: [PATCH] ipv6: fix two typos in a comment in xfrm6_init()

From: Steffen Klassert <steffen.klassert@secunet.com>
Date: 2012-11-09 07:57:33

On Thu, Nov 08, 2012 at 02:59:39PM -0500, David Miller wrote:
From: Steffen Klassert <steffen.klassert@secunet.com>
quoted
The routing cache is removed, so this comment is obsolete. But it reminds
me that we set the gc threshold to ip_rt_max_size/2 in ipv4. With the
routing cache removal patch, ip_rt_max_size was set to INT_MAX. So the gc
starts to remove entries when a threshold of INT_MAX/2 is reached.

cat /proc/sys/net/ipv4/xfrm4_gc_thresh
1073741823

I guess this was not intentional.
Do you mean for IPSEC routes?  For non-IPSEC routes on ipv4 there
is nothing to garbage collect.
Yes, I mean IPsec routes. We still cache them at the flow cache
and at sockets, so we should do some garbage collecting.

We could either go back to a static threshold, as it was before

git commit a33bc5c15154c835aae26f16e6a3a7d9ad4acb45
xfrm: select sane defaults for xfrm[4|6] gc_thresh

or do the same as ipv6 does. I'll take care of this.

Btw. it seems to me that the flow cache has similar limitations
as the routing cache had. At least I was able to fill the flow
cache with a nmap scan from a remote entity. In practice, it's
hard to DOS the flow cache because we use a Jenkins hash with
a random initialization value, but this was the same with the
routing cache.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help