2. kmemleak 概述
2.1 kmemleak 是什么
kmemleak（Kernel Memory Leak Detector）是 Linux 内核内置的一种内存泄漏检测机制，专门用于追踪内核空间中动态分配的内存块是否被正确释放。它通过周期性扫描和引用链分析，发现那些已经不再被任何内核数据结构引用但仍然占用物理内存的“孤立”对象。
kmemleak 的主要特点包括：
- 无侵入式检测：无需修改被测驱动代码，仅需内核配置开启即可运行。
- 运行时扫描：在系统运行过程中持续跟踪内存分配与释放，定期报告疑似泄漏。
- 引用链输出：当检测到泄漏时，输出从根引用集到泄漏对象的完整引用路径，辅助定位。
- 低性能开销：默认扫描间隔较长（10 分钟），适合长时间稳定性测试。
适用场景：kmemleak 特别适合驱动开发中的长期运行泄漏检测，例如网络驱动、存储驱动、GPU 驱动等需要频繁分配内核内存的模块。它能在功能测试和压力测试过程中自动捕获泄漏，无需人工插桩。
2.2 工作原理简介
kmemleak 的核心思想是引用可达性分析（类似用户态垃圾回收中的“标记-清扫”算法）。它维护一个全局的已分配对象红黑树，记录所有通过 kmalloc、vmalloc、kmem_cache_alloc 等接口分配的内存块。内核定期触发扫描线程，从一组预定义的根引用集（如任务栈、全局变量、内核栈）出发，遍历所有指针，标记可达对象。扫描结束后，未被标记的对象即被判定为泄漏。
关键数据结构：每个被跟踪的内存对象对应一个
kmemleak_object 结构体，包含分配栈回溯、引用计数、颜色标记（白/灰/黑）等信息。
下图展示了 kmemleak 的扫描流程与对象状态转换：
扫描过程中，kmemleak 使用三色标记法管理对象状态：
| 颜色 | 含义 | 处理动作 |
|---|---|---|
| 白色 | 未扫描（新分配或上次扫描后新增） | 加入待扫描队列 |
| 灰色 | 已扫描但引用的子对象尚未扫描 | 递归扫描其指针域 |
| 黑色 | 扫描完成且可达 | 保留，等待下次扫描 |
注意：kmemleak 的扫描基于指针值匹配，如果驱动将指针经过算术运算（如偏移、位操作）后存储，kmemleak 可能无法识别该引用，导致误报。这是 kmemleak 的主要局限性之一。
2.3 与其他内存检测工具的区别
Linux 内核提供了多种内存检测工具，各有侧重。kmemleak 专注于长期泄漏检测，而 KASAN 和 SLUB debug 则更擅长越界访问和释放后使用等内存破坏问题。下表从多个维度对比这三类工具：
| 对比维度 | kmemleak | KASAN | SLUB debug |
|---|---|---|---|
| 主要检测目标 | 内存泄漏（未释放） | 越界访问、释放后使用、双重释放 | 越界访问、释放后使用、重复释放、内存篡改 |
| 检测原理 | 引用可达性扫描 | 影子内存 + 编译插桩 | 红区（Redzone）+ 对象毒化（Poison） |
| 运行时开销 | 低（周期性扫描） | 高（每次访问都检查） | 中（分配/释放时检查） |
| 内存开销 | 约 1/8 影子内存 | 约 1/8 影子内存 | 每对象额外 2 个红区 |
| 是否需要重新编译 | 是（内核配置） | 是（GCC 插桩） | 是（内核配置） |
| 是否影响性能 | 几乎不影响（后台扫描） | 显著影响（2x~5x 变慢） | 轻微影响（分配/释放路径） |
| 适用阶段 | 长时间稳定性测试 | 开发调试、单元测试 | 开发调试、集成测试 |
| 误报率 | 中等（指针隐藏导致） | 低（精确检测） | 低（红区校验） |
下图从检测能力和性能开销两个维度直观对比三种工具：
2.4 工具选择建议
在驱动开发实践中，建议根据开发阶段灵活组合使用：
- 开发调试阶段：优先启用 KASAN 和 SLUB debug，快速捕获越界、释放后使用等显式错误。
- 功能验证阶段：关闭 KASAN（性能影响大），保留 SLUB debug 和 kmemleak，开始关注内存泄漏。
- 长时间稳定性测试：仅开启 kmemleak，配合自动化脚本定期检查
/sys/kernel/debug/kmemleak输出。
最佳实践：在驱动提交主线前，建议在
CONFIG_DEBUG_KERNEL=y 配置下同时开启 CONFIG_KASAN=y 和 CONFIG_DEBUG_KMEMLEAK=y，运行完整的 LTP（Linux Test Project）内存压力测试，确保无泄漏和越界问题。