lkml.org 
[lkml]   [2015]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Kernel 4.1.6 Panic due to slab corruption
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?


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.







\
 
 \ /
  Last update: 2015-09-08 17:01    [W:0.087 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site