Re: Kernel 4.1.6 Panic due to slab corruption

[Nikolay Borisov <kernel@kyup.com>]

On 09/08/2015 05:27 PM, Christoph Lameter wrote:
> On Tue, 8 Sep 2015, Nikolay Borisov wrote:
> 
>> Unfortunately I haven't found a way to reproduce it so the only option
>> would be to do this on a live server. However, the performance impact I
>> believe is going to be very prohibitive :(.  Alternatively what I could
>> do is probably leave merging on but enable debugging only for the
>> kmalloc-32 slab cache. Do you think this would provide enough
>> information to help track the corruption when it happens, without
>> impacting performance?
> 
> You have read https://www.kernel.org/doc/Documentation/vm/slub.txt?

I've read that I'm also following the merge/nomerge thread on the DM
mailing list. I guess my understanding is wrong in that if multiple slab
caches are merged, then it's enough to just instrument the cache to
which they are being merge in order to have them all instrumented? I
guess that's not the case, so even though slab caches might be merge
they are still somehow considered different entities in the kernel?

> 
> 
> The problem now is that merging is on so it could be that the corruption
> happens in one of the aliased caches. So maybe only kmalloc-32 wont do
> much good.
> 
> Run
> 
> 	slabinfo -a
> 
> (slabinfo.c is a tool in the kernel tree.)
> 
> to see the list of aliases for kmalloc-32.
> 
> You can also use slabinfo to enable some debugging at runtime. Just
> enabling sanity checks may catch something that allows us to track this to
> the subsystem.

I will experiment with slabinfo.