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

[David Rientjes]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/