Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1220894

Re: Kernel 4.1.6 Panic due to slab corruption

Show all headers | View raw

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Kernel 4.1.6 Panic due to slab corruption Nikolay Borisov <kernel@kyup.com> - 2015-09-07 10:50 +0200
  Re: Kernel 4.1.6 Panic due to slab corruption Holger Hoffstätte   <holger.hoffstaette@googlemail.com> - 2015-09-07 12:40 +0200
    Re: Kernel 4.1.6 Panic due to slab corruption Nikolay Borisov <kernel@kyup.com> - 2015-09-07 13:40 +0200
      Re: Kernel 4.1.6 Panic due to slab corruption Holger Hoffstätte   <holger.hoffstaette@googlemail.com> - 2015-09-07 13:50 +0200
        Re: Kernel 4.1.6 Panic due to slab corruption Holger Hoffstätte   <holger.hoffstaette@googlemail.com> - 2015-09-07 14:00 +0200
  Re: Kernel 4.1.6 Panic due to slab corruption Nikolay Borisov <kernel@kyup.com> - 2015-09-07 13:20 +0200
    Re: Kernel 4.1.6 Panic due to slab corruption Christoph Lameter <cl@linux.com> - 2015-09-08 16:00 +0200
      Re: Kernel 4.1.6 Panic due to slab corruption Nikolay Borisov <kernel@kyup.com> - 2015-09-08 16:10 +0200
        Re: Kernel 4.1.6 Panic due to slab corruption Christoph Lameter <cl@linux.com> - 2015-09-08 16:30 +0200
          Re: Kernel 4.1.6 Panic due to slab corruption Nikolay Borisov <kernel@kyup.com> - 2015-09-08 16:50 +0200
            Re: Kernel 4.1.6 Panic due to slab corruption Christoph Lameter <cl@linux.com> - 2015-09-08 17:20 +0200
              Re: Kernel 4.1.6 Panic due to slab corruption Nikolay Borisov <kernel@kyup.com> - 2015-09-09 13:50 +0200
                Re: Kernel 4.1.6 Panic due to slab corruption Christoph Lameter <cl@linux.com> - 2015-09-09 16:10 +0200
                Re: Kernel 4.1.6 Panic due to slab corruption Vlastimil Babka <vbabka@suse.cz> - 2015-09-09 18:30 +0200
                Re: Kernel 4.1.6 Panic due to slab corruption Christoph Lameter <cl@linux.com> - 2015-09-09 20:00 +0200
                Re: Kernel 4.1.6 Panic due to slab corruption Nikolay Borisov <kernel@kyup.com> - 2015-09-10 08:20 +0200
                Re: Kernel 4.1.6 Panic due to slab corruption Christoph Lameter <cl@linux.com> - 2015-09-10 18:40 +0200

csiph-web