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:27:43 +0800 [thread overview]
Message-ID: <02ee01cff25f$28808540$79818fc0$@gmail.com> (raw)
Hi, all:
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 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 reply other threads:[~2014-10-28 3:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-28 3:27 billbonaparte [this message]
[not found] <02ef01cff25f$29887f60$7c997e20$@gmail.com>
2014-10-28 3:37 ` netfilter: nf_conntrack: there maybe a bug in __nf_conntrack_confirm, when it race against get_next_corpse billbonaparte
2014-10-28 9:46 ` Florian Westphal
2014-10-28 10:11 ` Jesper Dangaard Brouer
-- strict thread matches above, loose matches on Subject: below --
2014-11-04 1:48 billbonaparte
2014-11-06 13:00 ` Jesper Dangaard Brouer
2014-11-04 1:52 billbonaparte
2014-11-07 6:47 Bill Bonaparte
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='02ee01cff25f$28808540$79818fc0$@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.