lkml.org 
[lkml]   [2015]   [Sep]   [9]   [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 Wed, 9 Sep 2015, Nikolay Borisov wrote:

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


Hmmmm.. Whats the problem here?

christoph@gentwo:/sys/kernel/slab/kmalloc-32$ ls -l
total 0
-r-------- 1 root root 4096 Sep 9 08:57 aliases
-r-------- 1 root root 4096 Sep 9 08:57 align
-r-------- 1 root root 4096 Sep 9 08:57 alloc_calls
-r-------- 1 root root 4096 Sep 9 08:57 cache_dma
-rw------- 1 root root 4096 Sep 9 08:57 cpu_partial
-r-------- 1 root root 4096 Sep 9 08:57 cpu_slabs
-r-------- 1 root root 4096 Sep 9 08:57 ctor
-r-------- 1 root root 4096 Sep 9 08:57 destroy_by_rcu
-r-------- 1 root root 4096 Sep 9 08:57 free_calls
-r-------- 1 root root 4096 Sep 9 08:57 hwcache_align
-rw------- 1 root root 4096 Sep 9 08:57 min_partial
-r-------- 1 root root 4096 Sep 9 08:57 objects
-r-------- 1 root root 4096 Sep 9 08:57 object_size
-r-------- 1 root root 4096 Sep 9 08:57 objects_partial
-r-------- 1 root root 4096 Sep 9 08:57 objs_per_slab
-rw------- 1 root root 4096 Sep 9 08:57 order
-r-------- 1 root root 4096 Sep 9 08:57 partial
-rw------- 1 root root 4096 Sep 9 08:57 poison
-rw------- 1 root root 4096 Sep 9 08:57 reclaim_account
-rw------- 1 root root 4096 Sep 9 08:57 red_zone
-rw------- 1 root root 4096 Sep 9 08:57 remote_node_defrag_ratio
-r-------- 1 root root 4096 Sep 9 08:57 reserved
-rw------- 1 root root 4096 Sep 9 08:57 sanity_checks
-rw------- 1 root root 4096 Sep 9 08:57 shrink
-r-------- 1 root root 4096 Sep 9 08:57 slabs
-r-------- 1 root root 4096 Sep 9 08:57 slabs_cpu_partial
-r-------- 1 root root 4096 Sep 9 08:57 slab_size
-rw------- 1 root root 4096 Sep 9 08:57 store_user
-r-------- 1 root root 4096 Sep 9 08:57 total_objects
-rw------- 1 root root 4096 Sep 9 08:57 trace
-rw------- 1 root root 4096 Sep 9 08:57 validate

Try

echo 1 >santy_checks


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

dmesg is the output channel for tracing.

What does:

echo 1 >trace

do? Could crash the sysem due to overload of messages.

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

Sanity checking is ok. But I would think you should be fine with enabling
full debugging on the particular caches of interest.



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