From: Patrick McHardy <kaber@trash.net>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: hemao77@gmail.com, bugme-daemon@bugzilla.kernel.org,
netdev@vger.kernel.org,
Netfilter Development Mailinglist
<netfilter-devel@vger.kernel.org>,
Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Subject: Re: [Bugme-new] [Bug 11058] New: DEADLOOP in kernel network module
Date: Wed, 09 Jul 2008 14:45:16 +0200 [thread overview]
Message-ID: <4874B2DC.2070305@trash.net> (raw)
In-Reply-To: <20080708210014.a1d3baf8.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 4274 bytes --]
Andrew Morton wrote:
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Tue, 8 Jul 2008 20:13:20 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote:
>
>> http://bugzilla.kernel.org/show_bug.cgi?id=11058
>>
>> Summary: DEADLOOP in kernel network module
>> ...
>> Problem Description:
>>
>> We have seen a deadloop in softirq and we got the cause by creating and
>> analysising the core dump of the kernel.I dont know where to submit a patch ,
>> so I report it here,wish you can apply it to furthur version of linux kernel.
>>
>> The Cause:
>>
>> Both ctnetlink_del_conntrack() and the tcp_packet() run
>> the code below:
>>
>> if (del_timer(&ct->timeout)) /*deactive the timer*/
>> ct->timeout.function((unsigned long) ct);/*remove conntrack from
>> conntrack table*/
>>
>> the ctnetlink_del_conntrack() context is:
>> ................
>> if (cda[CTA_ID-1]) {
>> u_int32_t id = ntohl(*(u_int32_t *)NFA_DATA(cda[CTA_ID-1]));
>> if (ct->id != id) {
>> ip_conntrack_put(ct);
>> return -ENOENT;
>> }
>> }
>> * if (del_timer(&ct->timeout))
>> * ct->timeout.function((unsigned long)ct);
>>
>> ip_conntrack_put(ct);
>> ...........
>>
>> the tcp_packet() context is:
>> ...........
>> case TCP_CONNTRACK_SYN_SENT:
>> if (old_state < TCP_CONNTRACK_TIME_WAIT)
>> break;
>> if ((conntrack->proto.tcp.seen[dir].flags &
>> IP_CT_TCP_FLAG_CLOSE_INIT)
>> || after(ntohl(th->seq),
>> conntrack->proto.tcp.seen[dir].td_end)) {
>> /* Attempt to reopen a closed connection.
>> * Delete this connection and look up again. */
>> write_unlock_bh(&tcp_lock);
>> * if (del_timer(&conntrack->timeout))
>> * conntrack->timeout.function((unsigned long)
>> * conntrack);
>> return -NF_REPEAT;
>> ......
>>
>> How the DEADLOOP happened?
>>
>> (1)in ctnetlink_del_conntrack()(runs in system call context): the del_timer
>> is called and then goes to timeout.function.
>> (2)before timeout.function finish excution(means the conntrack not
>> removed),an interrupt happens and a SYN packet of the same conntrack
>> comes.CPU goes to irq handle and enventually runs tcp_packet().
>> (3)in tcp_packet() ,del_timer() will fail because the timer was
>> already deleted. the timeout.function in tcp_packet will not run,
>> -NF_REPEAT is returned, the SYN packet will be passed back again.
>> (4)Neither side has the chance to run timeout.function,the
>> conntrack remains there,deadloop happen,the SYN packet will be passed back
>> again and again.
>>
>> The fix maybe,add lock the softirq when doing conntrack removing:
>> +++ local_bh_disable();
>> if (del_timer(&ct->timeout)) /*deactive the timer*/
>> ct->timeout.function((unsigned long) ct);/*remove conntrack from
>> conntrack table*/
>> +++ local_bh_enable();
>>
>> Thanks, may this be helpful.
>> My email: hemao77@gmail.com
>>
>> It is hard to reproduce , but it really happen on our linux box.
>>
>
> Thanks.
>
> Please submit patches via email as described in
> Documentation/SubmittingPatches. The file ./MAINTAINERS can be used to
> determine which individuals and mailing lists the patch should be sent to.
>
> But that's for next time - this patch is small enough for the netfilter
> developers to be able to type in again ;)
Good catch, thanks. Basically all del_timer()/timeout.function calls
in conntrack can happen in process context, so we'd have to disable
BHs every time we do this. I think this fix should also work. The
only spot where we return NF_REPEAT is in TCP conntrack, so we can
simply make sure we only do this if we actually managed to kill the
connection.
Jozsef, what do you think?
[patch for review against net-next, I'll backport it later unless
there are objections]
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 2754 bytes --]
diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h
index d5d76ec..15ce3fb 100644
--- a/include/net/netfilter/nf_conntrack.h
+++ b/include/net/netfilter/nf_conntrack.h
@@ -223,23 +223,23 @@ static inline void nf_ct_refresh(struct nf_conn *ct,
__nf_ct_refresh_acct(ct, 0, skb, extra_jiffies, 0);
}
-extern void __nf_ct_kill_acct(struct nf_conn *ct,
- enum ip_conntrack_info ctinfo,
- const struct sk_buff *skb,
- int do_acct);
+extern int __nf_ct_kill_acct(struct nf_conn *ct,
+ enum ip_conntrack_info ctinfo,
+ const struct sk_buff *skb,
+ int do_acct);
/* kill conntrack and do accounting */
-static inline void nf_ct_kill_acct(struct nf_conn *ct,
+static inline int nf_ct_kill_acct(struct nf_conn *ct,
enum ip_conntrack_info ctinfo,
const struct sk_buff *skb)
{
- __nf_ct_kill_acct(ct, ctinfo, skb, 1);
+ return __nf_ct_kill_acct(ct, ctinfo, skb, 1);
}
/* kill conntrack without accounting */
-static inline void nf_ct_kill(struct nf_conn *ct)
+static inline int nf_ct_kill(struct nf_conn *ct)
{
- __nf_ct_kill_acct(ct, 0, NULL, 0);
+ return __nf_ct_kill_acct(ct, 0, NULL, 0);
}
/* These are for NAT. Icky. */
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index 212a088..aad9585 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -848,10 +848,10 @@ acct:
}
EXPORT_SYMBOL_GPL(__nf_ct_refresh_acct);
-void __nf_ct_kill_acct(struct nf_conn *ct,
- enum ip_conntrack_info ctinfo,
- const struct sk_buff *skb,
- int do_acct)
+int __nf_ct_kill_acct(struct nf_conn *ct,
+ enum ip_conntrack_info ctinfo,
+ const struct sk_buff *skb,
+ int do_acct)
{
#ifdef CONFIG_NF_CT_ACCT
if (do_acct) {
@@ -862,8 +862,11 @@ void __nf_ct_kill_acct(struct nf_conn *ct,
spin_unlock_bh(&nf_conntrack_lock);
}
#endif
- if (del_timer(&ct->timeout))
+ if (del_timer(&ct->timeout)) {
ct->timeout.function((unsigned long)ct);
+ return 1;
+ }
+ return 0;
}
EXPORT_SYMBOL_GPL(__nf_ct_kill_acct);
diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c
index 740acd6..41032d2 100644
--- a/net/netfilter/nf_conntrack_proto_tcp.c
+++ b/net/netfilter/nf_conntrack_proto_tcp.c
@@ -844,7 +844,11 @@ static int tcp_packet(struct nf_conn *ct,
/* Attempt to reopen a closed/aborted connection.
* Delete this connection and look up again. */
write_unlock_bh(&tcp_lock);
- nf_ct_kill(ct);
+ /* The connection might be killed in parallel in process
+ * context. Don't repeat lookup so it gets a chance to
+ * complete. */
+ if (!nf_ct_kill(ct))
+ return -NF_DROP;
return -NF_REPEAT;
}
/* Fall through */
next prev parent reply other threads:[~2008-07-09 12:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-11058-10286@http.bugzilla.kernel.org/>
2008-07-09 4:00 ` [Bugme-new] [Bug 11058] New: DEADLOOP in kernel network module Andrew Morton
2008-07-09 12:45 ` Patrick McHardy [this message]
2008-07-09 13:27 ` Jozsef Kadlecsik
2008-07-09 15:00 ` Patrick McHardy
2008-07-09 16:32 ` Patrick McHardy
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=4874B2DC.2070305@trash.net \
--to=kaber@trash.net \
--cc=akpm@linux-foundation.org \
--cc=bugme-daemon@bugzilla.kernel.org \
--cc=hemao77@gmail.com \
--cc=kadlec@blackhole.kfki.hu \
--cc=netdev@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 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).