Re: [PATCH TRIVIAL] mm: Fix build warning in kmem_cache_create()

[David Rientjes <rientjes@google.com>]

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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>