Re: Kernel panic nf_nat_setup_info+0x5b3/0x6e0

[Patrick McHardy <kaber@trash.net>]

On 31.03.2011 16:47, Eric Dumazet wrote:
> Le jeudi 31 mars 2011 à 18:03 +0400, "Oleg A. Arkhangelsky" a écrit :
>>
>> 26.03.2011, 16:44, "Changli Gao" <xiaosuo@gmail.com>:
>>> On Thu, Mar 3, 2011 at 3:33 PM, Changli Gao <xiaosuo@gmail.com>; wrote:
>>>
>>>>  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