Re: [PATCH] netfilter: nf_conntrack: don't release a conntrack with non-zero refcnt

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Tue, Feb 04, 2014 at 12:29:25AM +0100, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> 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.