Re: ct: will ct be stalled in rcu read critical section?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Le mercredi 10 février 2010 à 16:43 +0800, Changli Gao a écrit :
> On Wed, Feb 10, 2010 at 3:43 PM, Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote:
> > Le mercredi 10 février 2010 à 11:16 +0800, Changli Gao a écrit :
> >
> > Because of lockless lookup (against writers), we must check the entry we
> > found - after getting a reference on it - is still matching the keys of
> > our lookup. If not, we retry the lookup, because the entry we found is
> > not what we wanted, ie we probably were linked to another hash chain.
> >
> 
> As we use RCU mechanism to protect connntrack table and its elements,
> so when the code in the read critical section runs, its elements won't
> be freed until the next quiescence period.

Please read about SLAB_DESTROY_BY_RCU, you dont know that part of RCU it
seems.

> 
> 
> > In real situation, probability of a matching then vanishing element,
> > reallocated and reused (since we could atomic_inc_not_zero() it), is
> > close to 0. Yet we must take care of this _very_ _unlikely_ event.
> >
> 
> reallocated and reused? If it happens, GOD will know what will happen
> next. The memory will be used by the other subsystems in the kernel,
> and in some case( just allocated, and its content isn't modified), the
> addition check here won't help much.
> 

You obviously missed a part of RCU. No grace period has to be respected
in this case. Just read again the Changelog of the patch, all this was
explained.



--
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

[Index of Archives]     [Netfitler Users]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux