On Mon, 16 Jul 2012, Christoph Lameter wrote: > > Sounds like a response from someone who is very familiar with slab > > allocators. The reality, though, is that very few people are going to be > > doing development with CONFIG_DEBUG_VM enabled unless they notice problems > > beforehand. > > Kernels are certainly run with CONFIG_DEBUG_VM before merges to mainstream > occur. If the developer does not do it then someone else will. > So let's say a developer wants to pass a dynamically allocated string to kmem_cache_create() for the cache name and it happens to be NULL because of a failed allocation but this never happened in testing (or it does happen but CONFIG_DEBUG_VM=n) and they are using CONFIG_SLAB. What would the failure be in linux-next? It looks like it would just result in a corrupted slabinfo. Bad result, we used to catch this problem before the extraction of common functionality and now we've allowed a corrupted slabinfo for nothing: optimizing kmem_cache_create() is pointless. > The kernel cannot check everything and will blow up in unexpected ways if > someone codes something stupid. There are numerous debugging options that > need to be switched on to get better debugging information to investigate > deper. Adding special code to replicate these checks is bad. > Disagree, CONFIG_SLAB does not blow up for a NULL name string and just corrupts userspace. -- 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/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>