On Tue, Feb 04, 2014 at 12:29:25AM +0100, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c > > index 4d1fb5d..356bef5 100644 > > --- a/net/netfilter/nf_conntrack_core.c > > +++ b/net/netfilter/nf_conntrack_core.c > > @@ -448,7 +448,9 @@ nf_conntrack_hash_check_insert(struct nf_conn *ct) > > goto out; > > > > add_timer(&ct->timeout); > > - nf_conntrack_get(&ct->ct_general); > > + smp_wmb(); > > + /* The caller holds a reference to this object */ > > + atomic_set(&ct->ct_general.use, 2); > > What happens when the skb is dropped before confirmation? If you refer to the spot above, conntracks added via ctnetlink are always confirmed and the refcount will become 1 after insertion into the hashes. In the packet path, the refcount is 1 for unconfirmed conntracks, so if you release the skbuff, nf_conntrack_put() is called and the conntrack is also released (fulfilling that refcount equals 0). > How is skb_clone etc. solved (it increments refcnt of underlying > conntrack object?) I think this works as before, this patch is just delaying the initial refcount bumping to 1 to make it once the conntrack is inserted in any of the lists. Please, let me know if you still see any problematic case. Thanks. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
