slab异常

wilbur512

内核版本3.0.74
arm， 2核

在执行lmbench内存压力测试时，发生了好几次slab异常，每次异常都是在这个地方：

1. kernel BUG at mm/slab.c:3067!
   
2. Unable to handle kernel NULL pointer dereference at virtual address 00000000
   
3. [color=Red]slabp->inuse:5,cachep->num:5[/color]
   
4. [<c003c6ec>] (__dabt_svc+0x4c/0x60) from [<c00405a4>] (__bug+0x1c/0x28)
   
5. [<c00405a4>] (__bug+0x1c/0x28) from [<c00c9d0c>] (cache_alloc_refill+0x3a0/0x654)
   
6. [<c00c9d0c>] (cache_alloc_refill+0x3a0/0x654) from [<c00ca174>] (kmem_cache_alloc+0xb0/0xc4)
   
7. [<c00ca174>] (kmem_cache_alloc+0xb0/0xc4) from [<c0057b04>] [color=Red](copy_process+0x9c/0xdbc)[/color]
   
8. [<c0057b04>] (copy_process+0x9c/0xdbc) from [<c0058890>] (do_fork+0x48/0x288)
   
9. [<c0058890>] (do_fork+0x48/0x288) from [<c003cc40>] (ret_fast_syscall+0x0/0x30)
   

复制代码

对应的语句是：
cache_alloc_refill函数的

1.                 /*
   
2.                  * The slab was either on partial or free list so
   
3.                  * there must be at least one object available for
   
4.                  * allocation.
   
5.                  */
   
6.                 BUG_ON(slabp->inuse >= cachep->num);

复制代码

根据函数的逻辑，代码走到这里的时候，说明刚从cache的partial或者free链表里取得了一个可用slab，
而这个获取的slab，一定是还有可用的obj，即slabp->inuse一定小于上限cachep->num

根据异常打印的信息
slabp->inuse:5,cachep->num:5
在正常情况下，打印task_struct_cache的num上限确实是5。


但代码走到了这里，并触发了BUG_ON，这是否说明：
1）这个版本的内核(3.0.74)是否有slab方面的bug？ 后期有修复的patch吗
2）是否这个arm架构的spinlock的实现有问题？

unbutun

这个问题建议思路尽量不要朝slab本身的错误去想，已经出了异常了，拿正常思路去推，肯定把自己陷进去了


比如踩内存，内存器件不稳定，都有可能，踩内存是最常出的，看第二次异常是freelist被弄坏了，在kfree的地方有没有对这个指针的合法性检查，多看下这个指针会在哪用到，如果用到的地没可疑，也有可能是飞踩过来的

建议尽量考虑试用者造成的问题

wilbur512

又复现了，异常时的信息：

1. [48373.310000] partial.next:df913000,free.next:df802df0
   
2. [48373.310000] slabs_partial pointer:df802de0,slabs_free pointer:df802df0
   
3. [48373.310000] We found error condition: cache 'task_struct'(5), slabp df913000(inuse:5,free:-257).
   
4. [48373.310000] get from partial
   
5. [48373.310000] slab: Internal list corruption detected in cache 'task_struct'(5), slabp df913000(5), entries 1, kmem_map vaddr:0xdf91301c
   
6. [48373.310000] Hexdump:
   
7. [48373.310000]
   
8. [48373.310000] 000: 00 50 90 df e0 2d 80 df 40 00 00 00 40 30 91 df
   
9. [48373.310000] 010: 05 00 00 00 ff fe ff ff 00 00 ad de 03 00 00 00
   
10. [48373.310000] 020: ff ff ff ff 00 00 00 00 ff fe ff ff ff ff ff ff

复制代码

上面的信息，说明是从task_struct_cache的 partial链表里取出了一个slab，slab的free字段是-257(0xfffffeff)，导致后续的一系列问题

Hexdump的 前面0x1c字节是slab描述符，后面的是slab的obj位图数据 =

1. struct slab {
   
2.         union {
   
3.                 struct {
   
4.                         struct list_head list;  0xdf905000,0xdf802de0
   
5.                         unsigned long colouroff; 0x40
   
6.                         void *s_mem;                /* including colour offset */ 0xdf913040
   
7.                         unsigned int inuse;        /* num of objs active in slab */ 0x5
   
8.                         kmem_bufctl_t free; 0xfffffeff:typedef unsigned int kmem_bufctl_t;
   
9.                         unsigned short nodeid;
   
10.                 };
    
11.                 struct slab_rcu __slab_cover_slab_rcu;
    
12.         };
    
13. };

复制代码

1. 问题就是，这个 0xfffffeff 是怎么出来的？slab描述符周围的值看上去都是正常的。
   
2. 怀疑是内存bit跳变

复制代码

，本来该slab已经满了，但由于slabp的free从fffffff变成fffffeff，因此不加入full list，而加入了partial_list，
下一次再分配slab的时候，就从
partial里取了一个非法的slab，导致分配时cache_alloc_refill里的BUG_ON被触发

1.         /* move slabp to correct slabp list: */
   
2.                 list_del(&slabp->list);
   
3.                 if (slabp->free == BUFCTL_END)
   
4.                         list_add(&slabp->list, &l3->slabs_full);
   
5.                 else
   
6.                         list_add(&slabp->list, &l3->slabs_partial);

复制代码

准备让硬件做一下ecc校验。

embeddedlwp

能否在最新的3.10上测一下？

embeddedlwp

回复 1# wilbur512

If you can reproduce against 3.10, I can fix it.


   

wilbur512

得port一堆驱动，有点麻烦， 测试用例就是lmbench的内存压力测试套件。

embeddedlwp

回复 5# wilbur512


ok，你能在x86+3.10上reproduce嘛？


   

jwwzhh

能解这个问题的人，薪水能达到多少啊？
在中国，有哪些公司需要这样的人啊？
这是我一直疑惑的地方。

embeddedlwp

回复 7# jwwzhh


能解决这个的只能是码农，拿着作为一个码农该拿的薪水。

   

jwwzhh

打击啊。解决这个问题，还只是拿一个普通码农的薪水？
还有，我现在做手机，方案公司的，没人会研究这么深入的。
所以不清楚，哪些公司会需要研究这么深入的。