slab memory的错误类型(2)

最新推荐文章于 2021-04-30 02:51:03 发布

shuai_wen

最新推荐文章于 2021-04-30 02:51:03 发布

阅读量2.2k

点赞数

CC 4.0 BY-SA版权

分类专栏： memory

本文链接：https://blog.youkuaiyun.com/u011279649/article/details/17998507

memory 专栏收录该内容

26 篇文章

订阅专栏

本文深入探讨了内存泄露现象，具体分析了在使用 slab 缓存机制时出现的问题，包括对象未被正确释放后仍被访问的情况。通过实例展示了内存地址的覆盖现象，并解释了打开 slab_debug 开关后可能导致的 crash。同时，提供了关于如何在 slab 缓存中正确使用对象的建议，以及如何避免内存泄露的方法。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

/******************************************************************/

1] use the object after free:

/*调用kmem_cache_free后，object就是inactive的，当有申请就会被分配
*一段时间后可能被回收。
*如果不打开slab_debug是不会有问题的，只是内容被改变而已; 打开则crash
**/
[   13.072735:0] Slab corruption (Tainted: G        W   ): my_cache start=ee14f478, len=32
[   13.081033:0] Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
[   13.087072:0] Last user: [<c02a3ec4>](slab_test+0x78/0xcc)
[   13.101280:0] 000: dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd ................
[   13.109835:0] 010: dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd dd ................
[   13.128925:0] Prev obj: start=ee14f440, len=32
[   13.146059:0] Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
[   13.152306:0] Last user: [< (null)>](0x0)
[   13.156688:0] 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[   13.165924:0] 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk.
[   13.175003:0] Next obj: start=ee14f4b0, len=32
[   13.180320:0] Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
[   13.187112:0] Last user: [< (null)>](0x0)
[   13.191314:0] 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[   13.203392:0] 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk.
[   13.212974:0] ------------[ cut here ]------------
[   13.217779:0] kernel BUG at mm/slab.c:2037!
[   13.221967:0] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[   13.227966:0] Modules linked in: memalloc
[   13.232018:0] CPU: 0    Tainted: G        W     (3.4.0-gc093057-dirty #596)
[   13.238986:0] PC is at check_poison_obj+0x194/0x1b4
[   13.243868:0] LR is at console_unlock+0x1c8/0x1d8

[   14.198441:0] Backtrace:
[   14.201081:0] [<c00d59fc>] (check_poison_obj+0x0/0x1b4) from [<c00d6938>] (slab_destroy+0x50/0x148)
[   14.210096:0] [<c00d68e8>] (slab_destroy+0x0/0x148) from [<c00d6d9c>] (drain_freelist+0xa0/0xc8)
[   14.218845:0] r8:ee14c1f0 r7:ee14c204 r6:00000001 r5:ee14ea00 r4:ee14c1e0
[   14.225564:0] r3:00000000
[   14.228377:0] [<c00d6cfc>] (drain_freelist+0x0/0xc8) from [<c00d6ea4>] (cache_reap+0xe0/0x140)
[   14.236963:0] [<c00d6dc4>] (cache_reap+0x0/0x140) from [<c004240c>] (process_one_work+0x274/0x420)
[   14.245883:0] r7:00000000 r6:c1130100 r5:c112b620 r4:ed8f5f20
[   14.251752:0] [<c0042198>] (process_one_work+0x0/0x420) from [<c0042954>] (worker_thread+0x1c4/0x2c4)
[   14.260940:0] [<c0042790>] (worker_thread+0x0/0x2c4) from [<c0048ad8>] (kthread+0x98/0xa4)
[   14.269177:0] [<c0048a40>] (kthread+0x0/0xa4) from [<c002e0d0>] (do_exit+0x0/0x758)

2] the used size beyond the application:

int slab_test(void)
{
   void *object;

   pr_err("slab_test: Cache name is %s\n", my_cachep->name);
   pr_err("slab_test: Cache object size is %d\n", kmem_cache_size(my_cachep));
   object = kmem_cache_alloc(my_cachep,GFP_KERNEL );
   if (object){
       pr_err("slab_test: get an object size 32 but used as 64 %p\n", object);
       memset(object, 0xDD, 64);
   }
   if(0){
       kmem_cache_free(my_cachep, object );
       memset(object, 0xee, 64);
   }
   trace_printk("slab_test: trace printk %p\n", object);
   pr_err("slab_test: after free but write still %p\n", object);

   return 0;
}

<3>[    4.509251:1] slabtest_driver_init
<3>[    4.513412:1] slab_test: Cache name is my_cache
<3>[    4.517997:1] slab_test: Cache object size is 32
<3>[    4.522887:1] slab_test: get an object size 32 but used as 64 ee296478
<3>[    4.529506:1] slab_test: after free but write still ee296478

ee296478 and ee2c0470
这里可能有点疑问：打印出来是 ee2c0478，通过命令kmem看到怎是ee2c0470.
不用忘了，如果slab_debug开关打开，会加上read zone and user caller等。

crash> kmem -S my_cache
CACHE    NAME                 OBJSIZE ALLOCATED     TOTAL SLABS SSIZE
ee17fa00 my_cache                  56          1        67      1     4k

SLAB      MEMORY    TOTAL ALLOCATED FREE
ee2c0000 ee2c0128     67          1    66
FREE / [ALLOCATED]

crash> rd FREE: ee2c0ef0 /*正常的还没使用的object*/
ee2c0ef0: 9d74e35b 09f91102 6b6b6b6b 6b6b6b6b   [.t.....kkkkkkkk
ee2c0f00: 6b6b6b6b 6b6b6b6b 6b6b6b6b 6b6b6b6b   kkkkkkkkkkkkkkkk
ee2c0f10: 6b6b6b6b a56b6b6b 9d74e35b 09f91102   kkkkkkk.[.t.....
[4*3*4 +2*4 = 48+8 =56]

/*如果写入的数据超过界限，也就是向后写，后面数据会被覆盖*/
crash> rd [ALLOCATED] ee2c0470
ee2c0470: 635688c0 d84156c5 dddddddd dddddddd   ..Vc.VA.........
ee2c0480: dddddddd dddddddd dddddddd dddddddd   ................
ee2c0490: dddddddd dddddddd dddddddd dddddddd   ................
ee2c04a0: dddddddd dddddddd dddddddd dddddddd   ................
ee2c04b0: dddddddd dddddddd
32有效字节的对象，却写入了64，结果就是覆盖。

/*请注意：此时看 kmalloc的 cache： size-xxx, 是没有包含red zone and user call的，但是

*poison element是起作用的，why?

**/

crash> kmem -S size-32
CACHE    NAME                 OBJSIZE ALLOCATED     TOTAL SLABS SSIZE
ee000080 size-32                   32      13959     16498    146     4k

crash> rd e82176c0 0x30
e82176c0: 6b6b6b6b 6b6b6b6b 6b6b6b6b 6b6b6b6b   kkkkkkkkkkkkkkkk
e82176d0: 6b6b6b6b 6b6b6b6b 6b6b6b6b a56b6b6b   kkkkkkkkkkkkkkk.