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

From: David Rientjes
Date: Mon Jul 16 2012 - 19:48:27 EST

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

> 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
Please read the FAQ at