Fwd: Memory exhaust issue with only IPsec policies configured on continuous traffic

4 messages, 2 authors, 2012-05-10 · open the first message on its own page

Fwd: Memory exhaust issue with only IPsec policies configured on continuous traffic

From: Nikhil Agarwal <hidden>
Date: 2012-05-10 05:23:43

Hi All,

Can you please help on this?

Regards
Nikhil

-----Original Message-----
From: Agarwal Nikhil-B38457
Sent: Wednesday, May 09, 2012 2:53 PM
To: linux-kernel@vger.kernel.org; netdev@vger.kernel.org
Subject: Memory exhaust issue with only IPsec policies configured on
continuous traffic

Hi all,
               In a typical scenario, when IPSEC policies are
configured in the system but SA is not present or negotiation fails or
IKE daemon is not running.  The current behavior of xfrm is to send
those matching packets to blackhole route.  i.e. xfrm_bundle_lookup
returns a bundle with null route and xfrm_lookup returns a blackhole
route.

For each of these packet a dst_alloc is called in
ipv4_blackhole_route. However when these skbs get free and their dst's
get discarded using dst_free and the garbage collector is scheduled
using cancel_delayed_work and schedule_delayed_work.

If the packets are coming continuously garbage collector may not get
scheduled and large amount of memory is stuck to be freed causing the
system to go into non-recoverable state.

Any ideas?

Regards
Nikhil

Re: Fwd: Memory exhaust issue with only IPsec policies configured on continuous traffic

From: Eric Dumazet <hidden>
Date: 2012-05-10 05:27:15

On Thu, 2012-05-10 at 10:53 +0530, Nikhil Agarwal wrote:
Hi All,

Can you please help on this?
Dont top post please
-----Original Message-----
From: Agarwal Nikhil-B38457
Sent: Wednesday, May 09, 2012 2:53 PM
To: linux-kernel@vger.kernel.org; netdev@vger.kernel.org
Subject: Memory exhaust issue with only IPsec policies configured on
continuous traffic

Hi all,
               In a typical scenario, when IPSEC policies are
configured in the system but SA is not present or negotiation fails or
IKE daemon is not running.  The current behavior of xfrm is to send
those matching packets to blackhole route.  i.e. xfrm_bundle_lookup
returns a bundle with null route and xfrm_lookup returns a blackhole
route.

For each of these packet a dst_alloc is called in
ipv4_blackhole_route. However when these skbs get free and their dst's
get discarded using dst_free and the garbage collector is scheduled
using cancel_delayed_work and schedule_delayed_work.

If the packets are coming continuously garbage collector may not get
scheduled and large amount of memory is stuck to be freed causing the
system to go into non-recoverable state.

Any ideas?
Yep, we can use DST_NOCACHE

Re: Fwd: Memory exhaust issue with only IPsec policies configured on continuous traffic

From: Eric Dumazet <hidden>
Date: 2012-05-10 05:32:09

On Thu, 2012-05-10 at 07:27 +0200, Eric Dumazet wrote:
Yep, we can use DST_NOCACHE
Please try following patch :
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 5773f5d..172c251 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2896,6 +2896,7 @@ struct dst_entry *ipv4_blackhole_route(struct net *net, struct dst_entry *dst_or
 	if (rt) {
 		struct dst_entry *new = &rt->dst;
 
+		new->flags |= DST_NOCACHE;
 		new->__use = 1;
 		new->input = dst_discard;
 		new->output = dst_discard;

Re: Fwd: Memory exhaust issue with only IPsec policies configured on continuous traffic

From: Nikhil Agarwal <hidden>
Date: 2012-05-10 09:43:19

If i disable this cache of DST, dst are working fine. But now XFRM
state is allocated for every incoming packet and then freed. But while
freeing the xfrm state same garbage collection logic is there. Now
since packets are coming continuously garbage collector may not get
scheduled and large amount of memory is stuck to be freed causing the
system to go into non-recoverable state.

It seems that ther should be some change garbage collection scheduling
logic or  some mechnism to decide wether to cache some entry or not.

On Thu, May 10, 2012 at 11:02 AM, Eric Dumazet [off-list ref] wrote:
quoted hunk
On Thu, 2012-05-10 at 07:27 +0200, Eric Dumazet wrote:
quoted
Yep, we can use DST_NOCACHE
Please try following patch :
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 5773f5d..172c251 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2896,6 +2896,7 @@ struct dst_entry *ipv4_blackhole_route(struct net *net, struct dst_entry *dst_or
       if (rt) {
               struct dst_entry *new = &rt->dst;

+               new->flags |= DST_NOCACHE;
               new->__use = 1;
               new->input = dst_discard;
               new->output = dst_discard;
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help