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. > 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. -- Regards， Changli Gao(xiaosuo@xxxxxxxxx) -- 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
