[Top] [All Lists]

Re: Conntrack leak (2.6.2rc2)

To: Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>
Subject: Re: Conntrack leak (2.6.2rc2)
From: Steve Hill <steve@xxxxxxxxxxxx>
Date: Mon, 2 Feb 2004 09:46:19 +0000 (GMT)
Cc: netdev@xxxxxxxxxxx
In-reply-to: <>
References: <>
Sender: netdev-bounce@xxxxxxxxxxx
On Mon, 2 Feb 2004, Jozsef Kadlecsik wrote:

> init_conntrack is called only when we have full, non-fragmented
> packets: ip_conntrack_in explicitly calls the proper function to gather
> the fragments before calling init_conntrack. There is no memory leak
> there.

From my observations, init_conntrack() is being called for each packet 
(not fragment, packet), which seems right.  destroy_conntrack() is, 
however, _not_ being called for any packets that are fragmented (i.e. it 
is not being called for the complete packet).  This is leading to the 
memory never being freed, and the conntrack count never being decremented 
even though the connection has been removed from the hash table.

There _is_ a memory leak here - it is observable and completely 
reproducable.  If I make a number of > MTU sized pings from a machine 
connected to one NIC to a machine connected another NIC (i.e. the packets 
will be fragmented), ip_conntrack_count grows until it reaches 
ip_conntrack_max, at which point it starts dropping new connections.  the 
ip_conntrack memory listed in /proc/slabinfo also grows.  Neither the 
memory or the connection count ever shrink again.

- Steve Hill
Senior Software Developer                        Email: steve@xxxxxxxxxxxx
Navaho Technologies Ltd.                           Tel: +44-870-7034015

        ... Alcohol and calculus don't mix - Don't drink and derive! ...

<Prev in Thread] Current Thread [Next in Thread>