On 31.03.2011 16:47, Eric Dumazet wrote:

Le jeudi 31 mars 2011 à 18:03 +0400, "Oleg A. Arkhangelsky" a écrit :

quoted

26.03.2011, 16:44, "Changli Gao" [off-list ref]:

quoted

On Thu, Mar 3, 2011 at 3:33 PM, Changli Gao [off-list ref]; wrote:

quoted

 Please try the patch attached and test if the problem is solved or not. Thanks.

Any feedback? Thanks.

Seems that patch is fine.

https://bugzilla.kernel.org/show_bug.cgi?id=21512

I wonder if this is not hiding another bug.

Adding an RCU grace period might reduce the probability window.

By the time nf_conntrack_free(ct) is called, no other cpu/thread
could/should use ct, or ct->ext ?

Sure, another thread can find/pass_on ct in a lookup but should not use
it, since its refcount (ct_general.use) should be 0.

Patrick ?

I think what's happening is that the conntrack entry is destroyed
and the NAT ct_extend destructor invoked, which removes the nat
extension from the RCU protected bysource hash, after which the
entire extension area is freed. Another CPU might still find the
old NAT entry with undefined contents in the hash though, so I
think using RCU to free the extension area is correct.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html