On Wed, 23 May 2012, Christoph Lameter wrote: > > No, it's not, there's no reason to prevent caches created before > > g_cpucache_up <= EARLY to be destroyed because it makes a patch easier to > > implement and then leave that little gotcha as an undocumented treasure > > for someone to find when they try it later on. > > g_cpucache_up <= EARLY is slab bootstrap code and the system is in a > pretty fragile state. Plus the the kmalloc logic *depends* on these > caches being present. Removing those is not a good idea. The other caches > that are created at that point are needed to create more caches. > > There is no reason to remove these caches. > Yes, we know that we don't want to remove the caches that are currently created in kmem_cache_init(), it would be a pretty stupid thing to do. I'm talking about the possibility of creating additional caches while g_cpucache_up <= EARLY in the future and then finding that you can't destroy them because of this string allocation. I don't think it's too difficult to statically allocate space for these names and then test for it before doing kfree() in kmem_cache_destroy(), it's not performance critical. -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
