From: Patrick McHardy <kaber@trash.net>
To: Jan Engelhardt <jengelh@medozas.de>
Cc: linux-rt-users@vger.kernel.org,
Netfilter Developer Mailing List
<netfilter-devel@vger.kernel.org>
Subject: Re: 2.6.29-rc bug near nf_conntrack_tuple_taken
Date: Tue, 24 Feb 2009 15:14:47 +0100 [thread overview]
Message-ID: <49A400D7.1010404@trash.net> (raw)
In-Reply-To: <alpine.LSU.2.00.0902240044320.8597@fbirervta.pbzchgretzou.qr>
Jan Engelhardt wrote:
> 2.6.29-rc4-rt2 spuriously locks up after 30 min to 2 h.
> First the network dies (no ping either to or from), later it
> takes the whole machine down as file I/O is blocked too.
>
> I have also observed this on a no-RT patched 2.6.29-rc4, though
> need to get a clean gpl trace there first.
>
> (Note that this -rt dump has not tainted.)
>
> Feb 23 19:15:11 yaguchi kernel: BUG: unable to handle kernel paging request at 00100100
> Feb 23 19:15:11 yaguchi kernel: IP: [<f0f305c4>] nf_conntrack_tuple_taken+0xe4/0x112 [nf_conntrack]
> Feb 23 19:15:13 yaguchi kernel: Call Trace:
> Feb 23 19:15:13 yaguchi kernel: [<f184367b>] ? nf_nat_used_tuple+0x1f/0x26 [nf_nat]
> Feb 23 19:15:13 yaguchi kernel: [<f1843817>] ? get_unique_tuple+0x195/0x1b6 [nf_nat]
> Feb 23 19:15:13 yaguchi kernel: [<f184391c>] ? nf_nat_setup_info+0xe4/0x2c6 [nf_nat]
> Feb 23 19:15:13 yaguchi kernel: [<f0efb522>] ? ipt_do_table+0x453/0x489 [ip_tables]
> Feb 23 19:15:13 yaguchi kernel: [<f185e115>] ? alloc_null_binding+0x89/0x91 [iptable_nat]
> Feb 23 19:15:13 yaguchi kernel: [<f185e164>] ? nf_nat_rule_find+0x47/0x4f [iptable_nat]
> Feb 23 19:15:13 yaguchi kernel: [<f185e34c>] ? nf_nat_fn+0x13c/0x1aa [iptable_nat]
> Feb 23 19:15:13 yaguchi kernel: [<f185e54b>] ? nf_nat_in+0x1e/0x4f [iptable_nat]
This would mean something has used the non-rcu list functions
when removing a conntrack from the hash. Which I don't see
happening anywhere. Another possibility would be that the connntrack
was already confirmed when the tuple got mangled and the list
got corrupted. The pr_debug in nf_conntrack_alter_reply should
trigger in that case.
next prev parent reply other threads:[~2009-02-24 14:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-23 23:49 2.6.29-rc bug near nf_conntrack_tuple_taken Jan Engelhardt
2009-02-24 14:14 ` Patrick McHardy [this message]
2009-02-25 23:35 ` Thomas Gleixner
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=49A400D7.1010404@trash.net \
--to=kaber@trash.net \
--cc=jengelh@medozas.de \
--cc=linux-rt-users@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.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.