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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
