From: "billbonaparte" <programme110@gmail.com>
To: <linux-kernel@vger.kernel.org>,
"'Netfilter Developer Mailing List'"
<netfilter-devel@vger.kernel.org>,
"'Pablo Neira Ayuso'" <pablo@netfilter.org>,
"'Patrick McHardy'" <kaber@trash.net>, <kadlec@blackhole.kfki.hu>,
<davem@davemloft.net>
Cc: "'Changli Gao'" <xiaosuo@gmail.com>,
"'Jozsef Kadlecsik'" <kadlec@blackhole.kfki.hu>,
"'Jesper Dangaard Brouer'" <brouer@redhat.com>,
"'Andrey Vagin'" <avagin@openvz.org>
Subject: netfilter: nf_conntrack: there maybe a bug in __nf_conntrack_confirm, when it race against get_next_corpse
Date: Tue, 28 Oct 2014 11:37:31 +0800 [thread overview]
Message-ID: <02f201cff260$8622e610$9268b230$@gmail.com> (raw)
In-Reply-To: <02ef01cff25f$29887f60$7c997e20$@gmail.com>
Hi, all:
sorry for sending this mail again, the last mail doesn't show text
clearly.
In function __nf_conntrack_confirm, we check the conntrack if it was
alreay dead, before insert it into hash-table.
we do this because if we insert an already 'dead' hash, it will
block further use of that particular connection.
but we don't do that right.
let's consider the following case:
cpu1 cpu2
__nf_conntrack_confirm get_next_corpse
lock corresponding hash-list ....
check nf_ct_is_dying(ct)
for_each_possible_cpu(cpu) {
......
spin_lock_bh(&pcpu->lock);
......
set_bit(IPS_DYING_BIT, &ct->status);
nf_ct_del_from_dying_or_unconfirmed_list(ct);
spin_unlock_bh(&pcpu_lock);
add_timer(&ct->timeout); }
ct->status |= IPS_CONFIRMD;
__nf_conntrack_hash_insert(ct); /* the conntrack has been seted as
dying*/
The above case reveal two problems:
1. we may insert a dead conntrack to hash-table, it will block
further use of that particular connection.
2. operation on ct->status should be atomic, because it race aginst
get_next_corpse.
due to this reason, the operation on ct->status in
nf_nat_setup_info should be atomic as well.
if we want to resolve the first problem, we must delete the
unconfirmed conntrack from unconfirmed-list first, then check if it is
already dead.
Am I right to do this ?
Appreciate any comments and reply.
next parent reply other threads:[~2014-10-28 3:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <02ef01cff25f$29887f60$7c997e20$@gmail.com>
2014-10-28 3:37 ` billbonaparte [this message]
2014-10-28 9:46 ` netfilter: nf_conntrack: there maybe a bug in __nf_conntrack_confirm, when it race against get_next_corpse Florian Westphal
2014-10-28 10:11 ` Jesper Dangaard Brouer
2014-11-07 6:47 Bill Bonaparte
-- strict thread matches above, loose matches on Subject: below --
2014-11-04 1:52 billbonaparte
2014-11-04 1:48 billbonaparte
2014-11-06 13:00 ` Jesper Dangaard Brouer
2014-10-28 3:27 billbonaparte
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='02f201cff260$8622e610$9268b230$@gmail.com' \
--to=programme110@gmail.com \
--cc=avagin@openvz.org \
--cc=brouer@redhat.com \
--cc=davem@davemloft.net \
--cc=kaber@trash.net \
--cc=kadlec@blackhole.kfki.hu \
--cc=linux-kernel@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=xiaosuo@gmail.com \
/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.