On Fri, 2016-08-19 at 18:04 +0200, Florian Westphal wrote: > Eric Dumazet <eric.duma...@gmail.com> wrote: > > On Fri, 2016-08-19 at 17:16 +0200, Florian Westphal wrote: > > > > > Hmm, ____nf_conntrack_find caller needs to hold rcu_read_lock, > > > in case object is free'd SLAB_DESTROY_BY_RCU should delay actual release > > > of the page. > > > > Well, point is that SLAB_DESTROY_BY_RCU means that we have no grace > > period, and object can be immediately reused and recycled. > > > > @next pointer can definitely be overwritten. > > I see. Isn't that detected by the nulls magic (to restart > lookup if entry was moved to other chain due to overwritten next pointer)?
Well, you did not add the nulls magic in your code ;) It might be fine, since it should be a rare event, and garbage collection is best effort, so you might add a comment in gc_worker() why it is probably overkill to restart the loop in this unlikely event. BTW, maybe nf_conntrack_tuple_taken() should get the nulls magic check, as it is currently missing. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
