Le mercredi 10 février 2010 à 11:16 +0800, Changli Gao a écrit : > in http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=ea781f197d6a835cbb93a0bf88ee1696296ed8aa#patch6 > , I don't understand the patch bellow. > > @@ -275,11 +291,18 @@ nf_conntrack_find_get(struct net *net, const > struct nf_conntrack_tuple *tuple) > struct nf_conn *ct; > > rcu_read_lock(); > +begin: > h = __nf_conntrack_find(net, tuple); > if (h) { > ct = nf_ct_tuplehash_to_ctrack(h); > if (unlikely(!atomic_inc_not_zero(&ct->ct_general.use))) > h = NULL; > + else { > + if (unlikely(!nf_ct_tuple_equal(tuple, &h->tuple))) { > + nf_ct_put(ct); > + goto begin; > + } > + } > } > rcu_read_unlock(); > > will ct be stalled in rcu read critical section? > > Would you explain it for me? Thanks! > I must confess I dont understand your question. If your question is "Can we loop forever, with RCU hold", the answer is no. 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. 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. -- 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
