From: Patrick McHardy <kaber@trash.net>
To: Tobias DiPasquale <codeslinger@gmail.com>
Cc: netdev <netdev@oss.sgi.com>,
linux-net <linux-net@vger.kernel.org>,
netfilter <netfilter-devel@lists.netfilter.org>
Subject: Re: deleting a conntrack record
Date: Thu, 17 Jun 2004 18:42:35 +0200 [thread overview]
Message-ID: <40D1C9FB.1070802@trash.net> (raw)
In-Reply-To: <876ef97a04061709173c8f1a09@mail.gmail.com>
Tobias DiPasquale wrote:
> On Thu, 17 Jun 2004 18:02:16 +0200, Patrick McHardy <kaber@trash.net> 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
next prev parent reply other threads:[~2004-06-17 16:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-17 15:07 deleting a conntrack record Tobias DiPasquale
2004-06-17 15:20 ` Antony Stone
2004-06-17 15:31 ` Tobias DiPasquale
2004-06-17 16:02 ` Patrick McHardy
2004-06-17 16:17 ` Tobias DiPasquale
2004-06-17 16:42 ` Patrick McHardy [this message]
2004-06-17 23:03 ` Tobias DiPasquale
-- strict thread matches above, loose matches on Subject: below --
2004-06-17 11:39 Tobias DiPasquale
2004-06-17 11:43 ` Tobias DiPasquale
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40D1C9FB.1070802@trash.net \
--to=kaber@trash.net \
--cc=codeslinger@gmail.com \
--cc=linux-net@vger.kernel.org \
--cc=netdev@oss.sgi.com \
--cc=netfilter-devel@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.