From: Tobias DiPasquale <codeslinger@gmail.com>
To: 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 12:17:39 -0400 [thread overview]
Message-ID: <876ef97a04061709173c8f1a09@mail.gmail.com> (raw)
In-Reply-To: <40D1C088.4090307@trash.net>
On Thu, 17 Jun 2004 18:02:16 +0200, Patrick McHardy <kaber@trash.net> wrote:
> Why don't you just adjust the timeout values in
> /proc/sys/net/ipv4/netfilter ?
Can't, because I only want to shorten the lifespans of some particular
TCP connections and also when I delete a record I need to do some
other stuff that's associated with the destruction of that connection.
> 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.
I have printed the integral value of the ct_general.use variable out
in order to confirm this on many occassions. If this is not the case,
then something extremely weird is going on with my kernel.
(btw, the kernel is a kernel.org 2.4.26 with the clear_fpu and the
2.4.26 LKCD (from the ML) patch applied)
--
[ Tobias DiPasquale ]
0x636f6465736c696e67657240676d61696c2e636f6d
next prev parent reply other threads:[~2004-06-17 16:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-17 15:07 deleting a conntrack record Tobias DiPasquale
2004-06-17 16:02 ` Patrick McHardy
2004-06-17 16:17 ` Tobias DiPasquale [this message]
2004-06-17 16:42 ` Patrick McHardy
2004-06-17 23:03 ` 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=876ef97a04061709173c8f1a09@mail.gmail.com \
--to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).