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, 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>