path: root/net/ipv4/xfrm4_policy.c
diff options
authorSteffen Klassert <steffen.klassert@secunet.com>2012-11-13 08:52:24 +0100
committerSteffen Klassert <steffen.klassert@secunet.com>2012-11-13 09:15:07 +0100
commit703fb94ec58e0e8769380c2877a8a34aeb5b6c97 (patch)
tree57bb3948dfe46f9dcd36b92ec4112408c7d5cc73 /net/ipv4/xfrm4_policy.c
parenta66fe1653f4e81c007a68ca975067432a42df05b (diff)
xfrm: Fix the gc threshold value for ipv4
The xfrm gc threshold value depends on ip_rt_max_size. This value was set to INT_MAX with the routing cache removal patch, so we start doing garbage collecting when we have INT_MAX/2 IPsec routes cached. Fix this by going back to the static threshold of 1024 routes. Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Diffstat (limited to 'net/ipv4/xfrm4_policy.c')
1 files changed, 1 insertions, 12 deletions
diff --git a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c
index 05c5ab8d983c..3be0ac2c1920 100644
--- a/net/ipv4/xfrm4_policy.c
+++ b/net/ipv4/xfrm4_policy.c
@@ -279,19 +279,8 @@ static void __exit xfrm4_policy_fini(void)
-void __init xfrm4_init(int rt_max_size)
+void __init xfrm4_init(void)
- /*
- * Select a default value for the gc_thresh based on the main route
- * table hash size. It seems to me the worst case scenario is when
- * we have ipsec operating in transport mode, in which we create a
- * dst_entry per socket. The xfrm gc algorithm starts trying to remove
- * entries at gc_thresh, and prevents new allocations as 2*gc_thresh
- * so lets set an initial xfrm gc_thresh value at the rt_max_size/2.
- * That will let us store an ipsec connection per route table entry,
- * and start cleaning when were 1/2 full
- */
- xfrm4_dst_ops.gc_thresh = rt_max_size/2;