lkml.org 
[lkml]   [2015]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Kernel 4.1.6 Panic due to slab corruption
    From
    Date


    On 09/08/2015 06:15 PM, Christoph Lameter wrote:
    > On Tue, 8 Sep 2015, Nikolay Borisov wrote:
    >
    >>> 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?
    >
    > Enabling debugging on bootup disables merging.
    >
    > If you switch debug options later then its possible to affect all aliases
    > caches. But then these option changes are only allowed to be used in such
    > a way as to not affect the object layout. You can switch on sanity checks
    > and double free checks I believe but nothing else.

    I tried the following:

    [root@kernighan vm]# ./slabinfo -da kmalloc-32
    Cannot write to dma-kmalloc-32/sanity
    [root@kernighan vm]# ./slabinfo -dF kmalloc-32
    Cannot write to dma-kmalloc-32/sanity
    [root@kernighan vm]# ./slabinfo -dz kmalloc-32
    kmalloc-32 not empty cannot enable redzoning
    [root@kernighan vm]# ./slabinfo -dp kmalloc-32
    kmalloc-32 not empty cannot enable poisoning
    [root@kernighan vm]# ./slabinfo -du kmalloc-32
    kmalloc-32 not empty cannot enable tracking
    [root@kernighan vm]# ./slabinfo -dt ^kmalloc-32$
    kmalloc-32 can only enable trace for one slab at a time

    I did however had success with enabling tracing but couldn't see where
    the output is produced - tried dmesg and the ftrace buffer but nothing
    turned up.

    But it seems it is not possible to enable any debugging whatsoever, so I
    will restor to doing it at boot time. In this case can you advice which
    options might not result in very high performance degradation - I'm
    thinking of sanity checking and maybe redzoning?


    > --
    > 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/
    >


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