kmemleak工具

最新推荐文章于 2024-09-29 17:27:18 发布
最新推荐文章于 2024-09-29 17:27:18 发布
阅读量989 收藏 1
点赞数 1
分类专栏： Linux stability 文章标签： linux
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/lzhf1122/article/details/128711672
版权

kmemleak工具

前言

内存泄漏分为用户态的内存泄漏和内核态的内存泄漏，我们本文主要关注的是内核态的内存泄漏。工作中比较常见的内存泄漏按照发生泄漏的频率可以划分以下几种类型：
1、一次性内存泄漏，只在初始化过程中或某一次条件触发产生的内存泄漏。
2、偶发性内存泄漏，在某种条件下偶尔触发产生的内存泄漏。
3、频发性内存泄漏，内存泄漏点被频繁的触发。

对于频发性内存泄漏我们有比较多的调试手段去定位，比如我们可以先通过/proc/meminfo信息大致确定下内存泄漏发生在哪个模块中，再通过其他手段进一步定位。如果观察到vmalloc异常，可以通过/proc/vmallocinfo信息分析定位。如果观察到slab内存异常，可以通过slabinfo和/sys/kernel/slab/*/alloc_calls或free_calls去辅助定位问题。而对于一次性的或者偶发性的内存泄漏确很难去通过/proc/meminfo信息快速分析定位，且大量的一次性或偶发性内存泄漏，同样给系统造成额外的内存压力。而本文介绍的kmemleak工具为各种类型的内存泄漏提供了一种检测方法。

KMEMLEAK原理

kmemleak(kernel memory leak detector)是检测内核空间的内存泄漏的调试工具。检测对象是memblock_alloc、kmalloc、vmalloc、kmem_cache_alloc等函数分配的内存块，该内存块由struct kmemleak_object来描述(简称为object)。kmemleak的实现原理非常简单，通过暴力扫描内存（假定内存中存放的都是指针，以ARM64为例，每次扫描8个字节)，如果找不到指向起始地址或者内存块任何位置的指针，则分配的内存块被认为是孤立的。这意味着内核可能无法将分配内存块的地址传递给释放函数，因此该内存块被视为内存泄漏。内存块(object)有3种颜色，分别为黑色、白色、灰色， 通过count和min_count区分不同颜色的object。

  • 黑色: min_count = -1，表示被忽略的object，此object不包含对别人的引用，也不会存在内存泄漏，比如代码段会标记为黑色。

  • 白色: count < min_count，孤立的object，没有足够的引用指向这个object，一轮扫描结束后被认为泄漏的内存块。

  • 灰色: min_count = 0，表示不是孤立的object，即不存在内存泄漏的object，如代码中主动标记object为灰色，防止误报（如data、bss、ro_after_init）。或者count >= min_count，对该object有足够的指针引用，认为不存在内存泄漏的内存块。

具体检测步骤如下：

1、通过struct kmemleak_object(简称为object)描述kmalloc、vmalloc、kmem_cache_alloc等函数申请的内存块，记录申请内存的起始地址，大小、call trace等信息。同时把object加入到红黑树object_tree_root和双向链表object_list中，红黑树中的key值为内存块的起始地址。

2、遍历双向链表object_list，把所有的object的count计数清0，即在新的一轮扫描前，尽可能的把能复位成白色的object标记为白色。然后判断object是否是灰色(默认data、bss、ro_after_init段会被标记为灰色)，如果是灰色的object则把object加入到灰色链表gray_list中。

3、扫描内存中可能存放指针的内存区域(per-cpu段、struct page的内容、内核栈、灰色链表),根据挂在红黑树中所有的object的地址范围进行对比。如果有指针指向某一个object(指向该object的起始地址或者指向object地址范围内)，会把object对应的count字段增加1，如果object变成灰色，则会把object加入到灰色链表中。

4、扫描object_list中的白色对象的object，判断object所描述的地址范围的内容的crc值是否发生变化，如果发生变化，则同样把object加入到灰色链表gray_list中。说明通过间接的方式访问了object描述的地址范围，不是内存泄漏，减少误报。

5、重新扫描灰色链表，因为步骤4中，可能有些白色的object加入到了灰色链表中，需要重新扫描。

6、经过上述一系列的扫描，剩余白色的object就是可疑的内存泄漏点。

开启KMEMLEAK功能

如果定义了CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF宏或者通过cmdline设置为kmemleak=off，则默认关闭kmemleak。如果cmdline中设置kmemleak=on，则表示默认开启kmemleak功能。如果没有定义CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF宏，则默认是开启kmemleak功能

9155 CONFIG_HAVE_DEBUG_KMEMLEAK=y
9156 CONFIG_DEBUG_KMEMLEAK=y
9157 CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE=16000
9158 # CONFIG_DEBUG_KMEMLEAK_TEST is not set
9159 # CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF is not set
9160 # CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN is not set

测试用例

kmemleak-test.c

// SPDX-License-Identifier: GPL-2.0-only
/*
 * samples/kmemleak/kmemleak-test.c
 *
 * Copyright (C) 2008 ARM Limited
 * Written by Catalin Marinas <catalin.marinas@arm.com>
 */

#define pr_fmt(fmt) "kmemleak: " fmt

#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/slab.h>
#include <linux/vmalloc.h>
#include <linux/list.h>
#include <linux/percpu.h>
#include <linux/fdtable.h>

#include <linux/kmemleak.h>

struct test_node {
	long header[25];
	struct list_head list;
	long footer[25];
};

static LIST_HEAD(test_list);
static DEFINE_PER_CPU(void *, kmemleak_test_pointer);

/*
 * Some very simple testing. This function needs to be extended for
 * proper testing.
 */
static int __init kmemleak_test_init(void)
{
	struct test_node *elem;
	int i;

	pr_info("Kmemleak testing\n");

	/* make some orphan objects */
	pr_info("kmalloc(32) = %p\n", kmalloc(32, GFP_KERNEL));
	pr_info("kmalloc(32) = %p\n", kmalloc(32, GFP_KERNEL));
	pr_info("kmalloc(1024) = %p\n", kmalloc(1024, GFP_KERNEL));
	pr_info("kmalloc(1024) = %p\n", kmalloc(1024, GFP_KERNEL));
	pr_info("kmalloc(2048) = %p\n", kmalloc(2048, GFP_KERNEL));
	pr_info("kmalloc(2048) = %p\n", kmalloc(2048, GFP_KERNEL));
	pr_info("kmalloc(4096) = %p\n", kmalloc(4096, GFP_KERNEL));
	pr_info("kmalloc(4096) = %p\n", kmalloc(4096, GFP_KERNEL));
#ifndef CONFIG_MODULES
	pr_info("kmem_cache_alloc(files_cachep) = %p\n",
		kmem_cache_alloc(files_cachep, GFP_KERNEL));
	pr_info("kmem_cache_alloc(files_cachep) = %p\n",
		kmem_cache_alloc(files_cachep, GFP_KERNEL));
#endif
	pr_info("vmalloc(64) = %p\n", vmalloc(64));
	pr_info("vmalloc(64) = %p\n", vmalloc(64));
	pr_info("vmalloc(64) = %p\n", vmalloc(64));
	pr_info("vmalloc(64) = %p\n", vmalloc(64));
	pr_info("vmalloc(64) = %p\n", vmalloc(64));

	/*
	 * Add elements to a list. They should only appear as orphan
	 * after the module is removed.
	 */
	for (i = 0; i < 10; i++) {
		elem = kzalloc(sizeof(*elem), GFP_KERNEL);
		pr_info("kzalloc(sizeof(*elem)) = %p\n", elem);
		if (!elem)
			return -ENOMEM;
		INIT_LIST_HEAD(&elem->list);
		list_add_tail(&elem->list, &test_list);
	}

	for_each_possible_cpu(i) {
		per_cpu(kmemleak_test_pointer, i) = kmalloc(129, GFP_KERNEL);
		pr_info("kmalloc(129) = %p\n",
			per_cpu(kmemleak_test_pointer, i));
	}

	return 0;
}
module_init(kmemleak_test_init);

static void __exit kmemleak_test_exit(void)
{
	struct test_node *elem, *tmp;

	/*
	 * Remove the list elements without actually freeing the
	 * memory.
	 */
	list_for_each_entry_safe(elem, tmp, &test_list, list)
		list_del(&elem->list);
}
module_exit(kmemleak_test_exit);

MODULE_LICENSE("GPL");

Makefile

# SPDX-License-Identifier: GPL-2.0-only
export ARCH=arm64
export CROSS_COMPILE=aarch64-linux-gnu-

KERNEL_DIR ?=~/linux_rt/linux-rt-5.15/
obj-m := kmemleak-test.o

modules:
	$(MAKE) -C $(KERNEL_DIR) M=$(PWD) modules

clean:
	$(MAKE) -C $(KERNEL_DIR) M=$(PWD) clean

install:
	cp *.ko $(KERNEL_DIR)/kmodules

运行结果

加载模块，触发内存泄漏检测：

insmod kmemleak-test.ko
echo scan > /sys/kernel/debug/kmemleak

查看结果如下：

[root@liebao kmemleak]# cat /sys/kernel/debug/kmemleak
unreferenced object 0xffff000006d3a400 (size 1024):
  comm "insmod", pid 1040, jiffies 4295348039 (age 1046.512s)
  hex dump (first 32 bytes):
    00 e0 b2 45 00 00 00 00 17 00 00 00 01 00 01 00  ...E............
    00 90 b2 45 00 00 00 00 0b 00 00 00 03 00 02 00  ...E............
  backtrace:
    [<(____ptrval____)>] slab_post_alloc_hook+0x7c/0x260
    [<(____ptrval____)>] kmem_cache_alloc_trace+0x188/0x358
    [<(____ptrval____)>] 0xffff8000010950a0
    [<(____ptrval____)>] do_one_initcall+0x50/0x2b0
    [<(____ptrval____)>] do_init_module+0x50/0x1e8
    [<(____ptrval____)>] load_module+0x2184/0x2708
    [<(____ptrval____)>] __do_sys_init_module+0x1e8/0x228
    [<(____ptrval____)>] __arm64_sys_init_module+0x24/0x30
    [<(____ptrval____)>] invoke_syscall+0x54/0x118
    [<(____ptrval____)>] el0_svc_common.constprop.3+0x90/0x118
    [<(____ptrval____)>] do_el0_svc+0x34/0xa0
    [<(____ptrval____)>] el0_svc+0x20/0x60
    [<(____ptrval____)>] el0t_64_sync_handler+0x88/0xb0
    [<(____ptrval____)>] el0t_64_sync+0x16c/0x170
unreferenced object 0xffff000006d3a800 (size 1024):
  comm "insmod", pid 1040, jiffies 4295348039 (age 1046.512s)
  hex dump (first 32 bytes):
    00 00 e0 48 00 00 00 00 0b 00 00 00 01 00 01 00  ...H............
    00 00 e6 48 00 00 00 00 00 10 00 00 03 00 02 00  ...H............
  backtrace:
    [<(____ptrval____)>] slab_post_alloc_hook+0x7c/0x260
    [<(____ptrval____)>] kmem_cache_alloc_trace+0x188/0x358
    [<(____ptrval____)>] 0xffff8000010950bc
    [<(____ptrval____)>] do_one_initcall+0x50/0x2b0
    [<(____ptrval____)>] do_init_module+0x50/0x1e8
    [<(____ptrval____)>] load_module+0x2184/0x2708
    [<(____ptrval____)>] __do_sys_init_module+0x1e8/0x228
    [<(____ptrval____)>] __arm64_sys_init_module+0x24/0x30
    [<(____ptrval____)>] invoke_syscall+0x54/0x118
    [<(____ptrval____)>] el0_svc_common.constprop.3+0x90/0x118
    [<(____ptrval____)>] do_el0_svc+0x34/0xa0
    [<(____ptrval____)>] el0_svc+0x20/0x60
    [<(____ptrval____)>] el0t_64_sync_handler+0x88/0xb0
    [<(____ptrval____)>] el0t_64_sync+0x16c/0x170
。。。

通过kmemleak report的输出信息，我们可以获取如下信息：
1、产生泄漏内存块对应的object的起始地址为0xffff000006d3a400 ，泄漏的大小为1024个字节。
2、进程名为insmod，pid为1040，创建object时的jiffies为1046.512s。
3、泄漏内存块的前32字节数据。
4、泄漏点的backtrace信息。

卸载模块，因没有free内存，会有新的内存泄漏

[root@liebao kmemleak]# rmmod kmemleak_test
[root@liebao kmemleak]# echo scan > /sys/kernel/debug/kmemleak
[10015.161611] kmemleak: 14 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
[root@liebao kmemleak]# cat /sys/kernel/debug/kmemleak
unreferenced object 0xffff000008c72c00 (size 256):
  comm "insmod", pid 1040, jiffies 4295348048 (age 8201.876s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<(____ptrval____)>] slab_post_alloc_hook+0x7c/0x260
    [<(____ptrval____)>] kmem_cache_alloc_trace+0x188/0x358
    [<(____ptrval____)>] 0xffff800001095268
    [<(____ptrval____)>] do_one_initcall+0x50/0x2b0
    [<(____ptrval____)>] do_init_module+0x50/0x1e8
    [<(____ptrval____)>] load_module+0x2184/0x2708
    [<(____ptrval____)>] __do_sys_init_module+0x1e8/0x228
    [<(____ptrval____)>] __arm64_sys_init_module+0x24/0x30
    [<(____ptrval____)>] invoke_syscall+0x54/0x118
    [<(____ptrval____)>] el0_svc_common.constprop.3+0x90/0x118
    [<(____ptrval____)>] do_el0_svc+0x34/0xa0
    [<(____ptrval____)>] el0_svc+0x20/0x60
    [<(____ptrval____)>] el0t_64_sync_handler+0x88/0xb0
    [<(____ptrval____)>] el0t_64_sync+0x16c/0x170
unreferenced object 0xffff000008c72d00 (size 256):
  comm "insmod", pid 1040, jiffies 4295348048 (age 8201.924s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<(____ptrval____)>] slab_post_alloc_hook+0x7c/0x260
    [<(____ptrval____)>] kmem_cache_alloc_trace+0x188/0x358
    [<(____ptrval____)>] 0xffff800001095268
    [<(____ptrval____)>] do_one_initcall+0x50/0x2b0
    [<(____ptrval____)>] do_init_module+0x50/0x1e8
    [<(____ptrval____)>] load_module+0x2184/0x2708
    [<(____ptrval____)>] __do_sys_init_module+0x1e8/0x228
    [<(____ptrval____)>] __arm64_sys_init_module+0x24/0x30
    [<(____ptrval____)>] invoke_syscall+0x54/0x118
    [<(____ptrval____)>] el0_svc_common.constprop.3+0x90/0x118
    [<(____ptrval____)>] do_el0_svc+0x34/0xa0
    [<(____ptrval____)>] el0_svc+0x20/0x60
    [<(____ptrval____)>] el0t_64_sync_handler+0x88/0xb0
    [<(____ptrval____)>] el0t_64_sync+0x16c/0x170
。。。

从调用栈看不到[<(ptrval)>] 0xffff800001095268这些地址对应的源代码，在kallsyms 搜索地址，发现在kmemleak_test模块里。另外可以借助objdump和addr2line工具看内存泄漏的代码行。
使用objdump时，发现pc值和实际代码有0x5000的偏移，不清楚是不是linux模块链接时，有没有相关操作，待确认。

[root@liebao kmemleak]# cat /proc/kallsyms | grep ffff8000010
ffff800001090000 t $x	[kmemleak_test]
ffff800001090000 t kmemleak_test_exit	[kmemleak_test]
ffff800001092000 d $d	[kmemleak_test]
ffff800001092000 d test_list	[kmemleak_test]
ffff800001091028 r $d	[kmemleak_test]
ffff800001092040 d $d	[kmemleak_test]
ffff800001091140 r $d	[kmemleak_test]
ffff800001091140 r _note_9	[kmemleak_test]
ffff800001091158 r _note_8	[kmemleak_test]
ffff800001092040 d __this_module	[kmemleak_test]
ffff800001090000 t cleanup_module	[kmemleak_test]
lzhf1122
关注
专栏目录
Linux内核态内存泄露检测工具——Kmemleak
Donge's Blog
06-22 1622
在Linux内核开发中，Kmemleak是一种用于检测内核中内存泄漏的工具。内存泄漏指的是程序中已经不再使用的内存没有被妥善地释放，导致内存的浪费。内核中的内存泄漏同样会导致系统性能下降、系统崩溃等问题。Kmemleak能够检测内核中的内存泄漏，通过检测内核中未被释放但又无法找到其使用位置的内存，进一步定位、修复内存泄漏的问题。在用户空间，我们常用Valgrind来检测；在内核空间，我们常用Kmemleak来检测。
kmemleak使用
ACMIII的博客
08-22 597
kmemleak是 Linux 内核中用于检测内存泄漏的工具，其设计目的是帮助开发人员发现内核中的内存分配与释放不匹配的情况。了解kmemleak的工作原理对开发和调试内核模块非常重要。下面将详细介绍kmemleak的原理、实现机制和相关细节。
kmemleak的使用---内存泄露检测工具【转】
weixin_33763244的博客
07-26 554
转自：http://blog.csdn.net/lishenglong666/article/details/8287783 版权声明：本文为博主原创文章，未经博主允许不得转载。   目录(?)[-] 内核泄露检测kmemleak 介绍 用法 功能实现的基本方法原理 Kmemleak API 处理假阳性阴性 限制和缺点 测试的特定部分kmemleak ...
kmemleak的使用
热门推荐
lishenglong666的专栏
12-12 1万+
内核泄露检测（kmemleak） 介绍： Kmemleak 提供了一种可选的内核泄漏检测，其方法类似于跟踪内存收集器。(http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Tracing_garbage_collectors)当独立的对象没有被释放时，其报告记录在 /sys/kernel/debug/km
linux kernel内存泄漏检测工具之kmemleak
yanghao23的专栏
04-27 1976
3.1 原理简介kmemleak实现方法是一个插桩加扫描过程, 它提供一个kmemleak_alloc桩函数，这个函数会在内核slab、vmalloc、alloc_bootmem、pcpu_alloc等函数分配接口中被调用，每次调用时该函数均会创建一个kmemleak object记录分配内存的相关信息比如内存地址，大小，调用栈等，并将这个object加入到一个rbtree里面;当内核释放内存时，也会调用kmemleak_free删除对应object。
【内存泄漏】＜kernel工具之kmemleak＞
luoye_369的博客
09-29 275
如果读者打算用gdb调试内核，将需要这些信息，还需要打开CONFIG_FRAME_POINTER。工具，启动一个内核线程扫描内存，每隔一定时间扫描内存（默认10分钟），并打印发现新的未引用对象数量。栈溢出的确切信号是不包含任何合理的反向跟踪信息的oops清单。第一个选项将在内核中增加明确的。第二个选项将让内核监视栈的使用（打印最大栈深度），并通过sysrq按键输出一些统计信息。在释放时，全部内存页从内核地址空间中移除。该选项将大大降低运行速度，但可以快速定位特定的。该选项将使内核的构造包含。
kmemleak下载安装
最新发布
10-03
`kmemleak`是一个用于检测Linux内核内存泄漏的小型工具，它可以帮助开发者定位可能导致系统资源耗尽的问题。以下是安装步骤： 1. **下载**: - 可从其GitHub仓库下载最新版本：访问...
kmemleak
wu7244582的专栏
03-24 565
开启方法 kernel hacking -> Memory Debugging -> Kernel memory leak detector 修改后的.config 文件如下： 重新编译内核，并替换vmlnuz # cp arch/x86/boot/bzImage /boot/vmlinuz-5.4.32 /sys/kernel/debug/kmemleak 存在表示开启memleak 监视内核内存泄漏成功，开启后会有一个内核线程kmemleak # echo cl.
kmemleak -检测内核中的内存泄漏工具
witch23333的博客
07-03 154
参考上面的文章。下面是自己的笔记。
【开发工具】【kmemleak】内存泄漏检测工具（kmemleak）的使用
诸葛一帆丶的博客
03-14 1390
检测对象是memblock_alloc、kmalloc、vmalloc、kmem_cache_alloc等函数分配的内存块，该内存块由struct kmemleak_object来描述(简称为object)。kmemleak的实现原理非常简单，通过暴力扫描内存（假定内存中存放的都是指针，以ARM64为例，每次扫描8个字节)，如果找不到指向起始地址或者内存块任何位置的指针，则分配的内存块被认为是孤立的。虽然kmemleak的扫描算法存在漏报和误报的可能，但是并不影响我们的使用。因此需要将值设置的大一些。
kmemleak的分析
04-24 464
1：检测内核内存泄漏的功能 2：Documentation/kmemleak.txt 3：内核demo:mm/kmemleak-test.c 对于kmemleak，需要理解下面三点就可以了 1：我们需要知道它能检测哪几种内存泄漏（即用什么方法分配的内存可以检测） 2：内核存在特殊情况，即分配内存但没有引用。使用什么方法可以防止kmemleak report 3：检测的机
内核检查内存泄漏的工具 --- kmemleak
chengwei_peng
03-12 7369
如何使用kmemleak检查内核内存泄漏？
内存泄漏工具kmemleak 使用方法
dachunfree的博客
07-22 1932
1.kmemleak使用方法 https://www.cnblogs.com/arnoldlu/p/8568090.html 2.英文手册 https://www.kernel.org/doc/html/latest/dev-tools/kmemleak.html 3.原理分析 http://blog.chinaunix.net/uid-26859697-id-5758036.html ...
Linux源码研究-内核开发工具-Kmemleak
金溪的博客
05-08 944
Kmemleak提供一种类似追踪垃圾回收的方式进行内存泄露检测方法。 用法 需要启用CONFIG_DEBUG_KMEMLEAK 显示所有可能的内存泄露： # mount -t debugfs nodev /sys/kernel/debug/ # cat /sys/kernel/debug/kmemleak 立即触发一个内存扫描 # echo scan &gt; /sys/kerne...
kmemleak的介绍
oqqYuJi12345678的博客
10-10 645
内核泄露检测（kmemleak）1 介绍： Kmemleak 提供了一种可选的内核泄漏检测，其方法类似于跟踪内存收集器。(http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Tracing_garbage_collectors)当独立的对象没有被释放时，其报告记录在 /sys/kernel/debug/kmemleak中。 2 用法： CONFIG_DEBUG_KMEMLEAK 在Kernel hacking中被使能
Kmemleak检测工具介绍
04-08 4312
一、 Kmemleak检测工具介绍 Kmemleak工作于内核态，Kmemleak 提供了一种可选的内核泄漏检测，其方法类似于跟踪内存收集器。当独立的对象没有被释放时，其报告记录在 /sys/kernel/debug/kmemleak中，Kmemcheck能够帮助定位大多数内存错误的上下文。 Kmemleak使用过程概述 首先CONFIG_DEBUG_KMEMLEAK 在Kernel hacki
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值