On Wed, 23 May 2012, Christoph Lameter wrote:

quoted

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@kvack.org.  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@kvack.org"> email@kvack.org </a>