netdev
[Top] [All Lists]

Re: deleting a conntrack record

To: Tobias DiPasquale <codeslinger@xxxxxxxxx>
Subject: Re: deleting a conntrack record
From: Patrick McHardy <kaber@xxxxxxxxx>
Date: Thu, 17 Jun 2004 18:42:35 +0200
Cc: netdev <netdev@xxxxxxxxxxx>, linux-net <linux-net@xxxxxxxxxxxxxxx>, netfilter <netfilter-devel@xxxxxxxxxxxxxxxxxxx>
In-reply-to: <876ef97a04061709173c8f1a09@mail.gmail.com>
References: <876ef97a0406170807663b89e0@mail.gmail.com> <40D1C088.4090307@trash.net> <876ef97a04061709173c8f1a09@mail.gmail.com>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5
Tobias DiPasquale wrote:
On Thu, 17 Jun 2004 18:02:16 +0200, Patrick McHardy <kaber@xxxxxxxxx> wrote:

The function passed to ip_ct_selective_cleanup is supposed to decide
if a conntrack should be destroyed by returning 0/1, not to do it
itself. ip_ct_selective_cleanup tries to destroy the already destroyed
conntrack.

This results in a memory leak in the conntrack slab cache. If you don't call ip_conntrack_put(), the conntrack entry leaves the ip_ct_selective_cleanup() function with a value >0 and thus is a permanent part of the scenery in RAM. As well, its been removed from the conntrack hash table, so it no longer appears in /proc/net/ip_conntrack, but you can see the effects by viewing /proc/slabinfo.

Now I remember - the reason why ctnetlink called ip_conntrack_put in ctnetlink_kill is because it uses ip_conntrack_find_get before, which increments the reference count. This is wrong because the conntrack is then destroyed immediately after returning 1 to ip_ct_selective_cleanup, but still used for comparing the tuple. You (and ctnetlink) need to call ip_conntrack_put after the call to ip_ct_selective_cleanup. In fact you shouldn't use ip_ct_selective_cleanup at all but destroy it yourself. You already have a reference, so there is no need to iterate through the entire hash.

Regards
Patrick

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