On Wed, 16 May 2012, Glauber Costa wrote: > > Index: linux-2.6/mm/slab_common.c > > =================================================================== > > --- linux-2.6.orig/mm/slab_common.c 2012-05-14 08:39:27.859145830 -0500 > > +++ linux-2.6/mm/slab_common.c 2012-05-14 08:39:29.827145790 -0500 > > @@ -98,6 +98,9 @@ struct kmem_cache *kmem_cache_create(con > > > > s = __kmem_cache_create(name, size, align, flags, ctor); > > > > + if (s&& s->refcount == 1) > > + list_add(&s->list,&slab_caches); > > + > > oops: > > I personally think that the refcount == 1 test is too fragile. > It happens to be true, and is likely to be true in the future, but there is no > particular reason that is *has* to be true forever. Its not fragile since a refcount will always be one for a slab that was just created. There is no possible other reference to it since the subsystem using it has never received a pointer to the kmem_cache struct yet. > Also, the only reasons it exists, seems to be to go around the fact that the > slab already adds the kmalloc caches to a list in a slightly different way. > And there has to be cleaner ways to achieve that. The reason it exists is to distinguish the case of an alias creation from a true kmem_cache instatiation. The alias does not need to be added to the list of slabs. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>