Required guidance to debug ipsec memory leak

Required guidance to debug ipsec memory leak

[Vakul Garg]

Hi

I need help to debug a suspected memory leak problem while running kernel ipsec with rekeying enabled.
I am using strongswan for tunnel creation/maintainence and using kernel 5.4 (with e1000 ethernet adapters) on cortex-a72 based quadcore cpu.

My setup uses hub-and-spoke model (1 hub and 2-spokes).
In all there are 4 tunnels.

When traffic is running, the kernel shows that 'used' memory (in ''free'' command output) gets incremented steadily.
The system keeps loosing memory and eventually after several hours, OOM killer gets invoked.

The memory usage does not increase if traffic is not run (and simply rekeying is happening).
The memory depletes faster if rekey time is decreased or if number of tunnels in increased.

'Kmemleak' does not show up anything.

I checked that number of states (i.e. net->xfrm.state_num) does not increase much and states are getting freed as expected.

Kindly guide me about what else to check.

Regards

Vakul

Re: Required guidance to debug ipsec memory leak

[Steffen Klassert]

On Mon, Nov 18, 2019 at 06:35:24AM +0000, Vakul Garg wrote:
> Hi
> 
> I need help to debug a suspected memory leak problem while running kernel ipsec with rekeying enabled.

Did you try with the current net tree? There is a fix for
such a leak:

commit 86c6739eda7d ("xfrm: Fix memleak on xfrm state destroy")

RE: Required guidance to debug ipsec memory leak

[Vakul Garg]

> -----Original Message-----
> From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org>
> On Behalf Of Steffen Klassert
> Sent: Monday, November 18, 2019 12:47 PM
> To: Vakul Garg <vakul.garg@nxp.com>
> Cc: netdev@vger.kernel.org
> Subject: Re: Required guidance to debug ipsec memory leak
> 
> On Mon, Nov 18, 2019 at 06:35:24AM +0000, Vakul Garg wrote:
> > Hi
> >
> > I need help to debug a suspected memory leak problem while running
> kernel ipsec with rekeying enabled.
> 
> Did you try with the current net tree? There is a fix for such a leak:
> 
> commit 86c6739eda7d ("xfrm: Fix memleak on xfrm state destroy")

Sorry for a late response. Thanks for the help. 
The given patch has helped in reducing the rate at which memory is leaking.

But we are still losing memory at rate of about 30-40MB per hour.

Any pointers in debugging would greatly help.