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
