On Mon, Feb 1, 2010 at 1:23 PM, Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote: > I wrote the algos, I know that we need different slab caches, for sure, > this is not something I can _measure_, but theory can predict. > > SLAB_DESTROY_BY_RCU has very special semantics, you can ask Paul E. > McKenny for details if you dont trust me. > > If you use a shared slab cache, one object can instantly flight between > one hash table (netns ONE) to another one (netns TWO), and concurrent > reader (doing a lookup in netns ONE, 'finding' an object of netns TWO) > can be fooled without notice, because no RCU grace period has to be > observed between object freeing and its reuse. > > We dont have this problem with UDP/TCP slab caches because TCP/UDP > hashtables are global to the machine (and each object has a pointer to > its netns). conntracks also have netns pointer (->ct_net). This should be enough, yes? > If we use per netns conntrack hash tables, we also *must* use per netns > conntrack slab caches, to guarantee an object can not escape from one > namespace to another one. -- 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
