LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Martin Josefsson <gandalf@wlug.westbo.se>
To: Patrick McHardy <kaber@trash.net>
Cc: Chuck Ebbert <cebbert@redhat.com>,
netfilter-devel@lists.netfilter.org,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Soft lockup on shutdown in nf_ct_iterate_cleanup()
Date: Sun, 25 Feb 2007 19:38:13 +0100 [thread overview]
Message-ID: <1172428694.4485.31.camel@localhost.localdomain> (raw)
In-Reply-To: <45E1C7E0.9070102@trash.net>
[-- Attachment #1: Type: text/plain, Size: 2131 bytes --]
On Sun, 2007-02-25 at 18:31 +0100, Patrick McHardy wrote:
> [NETFILTER]: conntrack: fix {nf,ip}_ct_iterate_cleanup endless loops
>
> {nf,ip}_ct_iterate_cleanup iterate over the unconfirmed list for cleaning
> up conntrack entries, which is wrong for multiple reasons:
>
> - unconfirmed entries can not be killed manually, which means we might
> iterate forever without making forward progress.
>
> This can happen in combination with the conntrack event cache, which
> holds a reference to the conntrack entry, which is only released when
> the packet makes it all the way through the stack or a different
> packet is handled.
>
> - taking references to an unconfirmed entry and using it outside the
> locked section doesn't work, the list entries are not refcounted and
> another CPU might already be waiting to destroy the entry
>
> Split ip_ct_iterate_cleanup in ip_ct_iterate, which iterates over both
> confirmed and unconfirmed entries, but doesn't attempt to kill them,
> and ip_ct_cleanup, which makes sure no unconfirmed entries exist by
> calling synchronize_net() prior to walking the conntrack hash.
What about this case:
1. Conntrack entry is created and placed on the unconfirmed list
2. The event cache bumps the refcount of the conntrack entry
3. module removal of ip_conntrack unregisters all hooks
4. packet is dropped by an iptables rule
5. packet is freed but we still have a refcount on the conntrack entry
Now there's no way to get that refcount to decrease as that only happens
when the event cache receives another packet or the current packet makes
it through the stack as you wrote above. And neither of this will happen
since we unregistered the hooks providing the packets and dropped the
packet.
I ran into this case a while ago during stresstesting and rewrote the
event cache to not increase the refcount, but this has the drawback that
events caused by dropped packets won't be reported. This may not be a
good thing...
Old patch can be found here:
http://performance.netfilter.org/patches/nf_conntrack_ecache-fix
--
/Martin
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-02-25 19:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-21 1:10 Chuck Ebbert
2007-02-22 0:56 ` Chuck Ebbert
2007-02-24 13:58 ` Patrick McHardy
2007-02-24 16:18 ` Chuck Ebbert
2007-02-25 17:31 ` Patrick McHardy
2007-02-25 18:38 ` Martin Josefsson [this message]
2007-02-25 19:03 ` Patrick McHardy
2007-02-26 17:14 ` Chuck Ebbert
2007-02-26 17:53 ` Patrick McHardy
2007-02-26 21:21 ` Chuck Ebbert
2007-02-28 18:09 ` Patrick McHardy
2007-02-28 20:30 ` Chuck Ebbert
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=1172428694.4485.31.camel@localhost.localdomain \
--to=gandalf@wlug.westbo.se \
--cc=cebbert@redhat.com \
--cc=kaber@trash.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netfilter-devel@lists.netfilter.org \
--subject='Re: Soft lockup on shutdown in nf_ct_iterate_cleanup()' \
/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
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).