[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D9B01DF.2050206@trash.net>
Date: Tue, 05 Apr 2011 13:49:51 +0200
From: Patrick McHardy <kaber@...sh.net>
To: Eric Dumazet <eric.dumazet@...il.com>
CC: "Oleg A. Arkhangelsky" <sysoleg@...dex.ru>,
Changli Gao <xiaosuo@...il.com>,
netfilter-devel@...r.kernel.org, netdev@...r.kernel.org,
Paul E McKenney <paulmck@...ux.vnet.ibm.com>
Subject: Re: Kernel panic nf_nat_setup_info+0x5b3/0x6e0
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@...il.com>:
>>> On Thu, Mar 3, 2011 at 3:33 PM, Changli Gao <xiaosuo@...il.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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists