From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp>
Cc: laforge@netfilter.org, netfilter-devel@lists.netfilter.org,
kaber@trash.net
Subject: Re: [PATCH 4/8][CTNETLINK] Fix race condition on conntrack creation
Date: Mon, 31 Jul 2006 13:15:01 +0200 [thread overview]
Message-ID: <44CDE635.9060101@netfilter.org> (raw)
In-Reply-To: <200607281316.k6SDGBVP001926@toshiba.co.jp>
Hi Yasuyuki,
Yasuyuki KOZAKAI wrote:
> From: Pablo Neira Ayuso <pablo@netfilter.org>
> Date: Tue, 25 Jul 2006 15:18:38 +0200
>
>
>> - rework get_features facility to avoid a softlockup
>
>
> This looks nice cleanup, but __nf_conntrack_alloc() cannot
> be called while holding nf_conntrack_lock, because it may call
> early_drop(), which holds nf_contrack_lock and also may call
> nf_ct_put().
>
>
>> static struct nf_conn *
>> __nf_conntrack_alloc(const struct nf_conntrack_tuple *orig,
>> const struct nf_conntrack_tuple *repl,
>>- const struct nf_conntrack_l3proto *l3proto)
>>+ const struct nf_conntrack_l3proto *l3proto,
>>+ u_int32_t features)
>> {
>
>
> You've moved "features = l3proto->get_features(orig);" out of
> this function, then the argument 'l3proto' isn't necessary.
Indeed, I also detected another problem related with the NAT code in
ip_conntrack_netlink, so this patch needs to be dropped.
I'm questioning the usefulness of this patch since nfnetlink
serializes the creation of two new conntracks.
> BTW, I think this race is similar situation in init_conntrack().
> It doesn't care about race and __nf_conntrack_confirm() does it
> instead.
>
> One more my concern is recent Patrick's proposal.
>
> https://lists.netfilter.org/pipermail/netfilter-devel/2006-July/025107.html
>
>
>>- change conntrack to always put connections in the hash immediately
>> and remove them again if the connection is dropped before beeing
>> confirmed.
>
> If we do this, we need to solve the same issue in init_conntrack().
> It might be time to consider to organize processing of hash and lock.
About the implementation, we can play around with refcounting, set
refcount to 1 if the conntrack is unconfirmed and increase it to 2 once
it gets confirmed.
--
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris
next prev parent reply other threads:[~2006-07-31 11:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-25 0:31 Netfilter Connection Tracking Race Condition in Kernel 2.4.x Bob Halley
2006-07-25 1:07 ` Patrick McHardy
2006-07-26 0:54 ` Phil Oester
2006-07-26 3:56 ` Patrick McHardy
2006-07-26 4:49 ` Yasuyuki KOZAKAI
2006-07-28 13:16 ` [PATCH 4/8][CTNETLINK] Fix race condition on conntrack creation Yasuyuki KOZAKAI
2006-07-31 11:15 ` Pablo Neira Ayuso [this message]
2006-08-04 14:43 ` Amin Azez
2006-08-08 10:19 ` Patrick McHardy
-- strict thread matches above, loose matches on Subject: below --
2006-07-25 13:18 Pablo Neira Ayuso
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=44CDE635.9060101@netfilter.org \
--to=pablo@netfilter.org \
--cc=kaber@trash.net \
--cc=laforge@netfilter.org \
--cc=netfilter-devel@lists.netfilter.org \
--cc=yasuyuki.kozakai@toshiba.co.jp \
/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.