1. 内存泄漏基础：定义、危害与典型场景

1.1 内存泄漏的定义

内存泄漏（Memory Leak）是指程序在运行过程中动态分配的内存（堆内存）在不再需要时未被正确释放，导致这部分内存无法被系统回收和重新利用。在 Linux 内核驱动开发中，内存泄漏特指通过 kmalloc()、kzalloc()、vmalloc() 等内核 API 分配的内存，在驱动卸载或功能路径结束后未调用 kfree()、vfree() 等释放函数。

内核内存泄漏与用户空间内存泄漏的关键区别在于：内核内存通常无法通过进程退出自动回收，一旦泄漏，只能通过重启系统或卸载并重新加载驱动模块来释放，对系统稳定性的影响更为严重。

1.2 内存泄漏在驱动开发中的危害

驱动运行在内核空间，其内存泄漏的危害远大于用户空间程序。以下是驱动内存泄漏的典型危害链：

1. 内核内存耗尽（OOM）：泄漏持续累积，系统可用内存逐渐减少，最终触发 OOM Killer 杀死关键进程，甚至导致系统完全挂死。
2. 系统性能持续下降：内存碎片化加剧，kmalloc() 分配大块连续内存的成功率降低，驱动响应变慢，用户态程序也因缺页中断增多而卡顿。
3. 驱动热插拔失败：驱动卸载时若存在未释放的内存，module_exit() 无法正常完成，导致设备无法重新绑定驱动，需要重启系统恢复。
4. 安全漏洞风险：泄漏的内存中可能包含敏感数据（密钥、用户密码等），若被其他内核模块或攻击者利用，会造成信息泄露。
5. 调试成本极高：内存泄漏通常不会立即触发崩溃，而是在系统运行数小时甚至数天后才暴露，定位根因需要大量时间和专业工具。

1.3 驱动开发中的典型泄漏场景分析

根据多年驱动开发经验，内存泄漏主要集中在以下 6 类典型场景中。理解这些场景有助于在编码阶段提前规避，也是后续使用 kmemleak 进行检测的基础。

场景一：错误路径中遗漏释放

驱动函数在正常路径中正确释放了内存，但在错误处理分支中遗漏了释放操作。这是最常见的泄漏类型。

// 错误示例：错误路径遗漏 kfree
static int example_probe(struct platform_device *pdev)
{
    struct priv_data *priv;
    int ret;

    priv = kzalloc(sizeof(*priv), GFP_KERNEL);
    if (!priv)
        return -ENOMEM;

    ret = some_init_function(priv);
    if (ret) {
        // 错误：此处未释放 priv，直接返回
        return ret;
    }

    platform_set_drvdata(pdev, priv);
    return 0;
}

// 正确做法：错误路径必须释放
static int example_probe(struct platform_device *pdev)
{
    struct priv_data *priv;
    int ret;

    priv = kzalloc(sizeof(*priv), GFP_KERNEL);
    if (!priv)
        return -ENOMEM;

    ret = some_init_function(priv);
    if (ret) {
        kfree(priv);  // 释放已分配的内存
        return ret;
    }

    platform_set_drvdata(pdev, priv);
    return 0;
}

场景二：数据结构生命周期管理混乱

驱动使用链表、树、哈希表等数据结构存储动态分配的对象，但在移除或替换对象时，只更新了指针引用，未释放原对象占用的内存。

场景三：引用计数失衡

内核对象（如 struct kobject、struct device）通过引用计数管理生命周期。驱动在 get() 和 put() 调用次数不匹配时，会导致对象永远无法被释放。

// 引用计数泄漏示例
static struct my_object *obj_create(void)
{
    struct my_object *obj;

    obj = kzalloc(sizeof(*obj), GFP_KERNEL);
    if (!obj)
        return NULL;

    kref_init(&obj->refcount);  // 初始计数 = 1
    // 驱动后续调用 kref_get() 增加计数
    // 但某条路径遗漏了 kref_put()，导致计数永远不为 0
    return obj;
}

场景四：DMA 缓冲区未释放

驱动使用 dma_alloc_coherent() 或 dma_map_single() 分配 DMA 缓冲区，但在设备断开或驱动卸载时未调用对应的 dma_free_coherent() 或 dma_unmap_single()。

场景五：定时器/工作队列中的内存

驱动在定时器回调或工作队列处理函数中分配内存，但定时器被取消或工作项被删除时，未清理已分配但尚未处理的内存。

场景六：ioctl 路径中的泄漏

用户态通过 ioctl() 与驱动交互，驱动在实现中为每个请求分配内存，但某些 ioctl 命令的处理路径遗漏了释放。

1.4 内存泄漏的检测思路

在驱动开发中，检测内存泄漏通常遵循以下层次化策略：

• 静态代码分析：使用 sparse、cppcheck 或 Coverity 在编译阶段发现明显的分配/释放不匹配。
• 内核配置检测：开启 CONFIG_DEBUG_SLAB、CONFIG_DEBUG_KMEMLEAK 等内核调试选项，在运行时捕获泄漏。
• kmemleak 扫描：周期性扫描内核内存，报告未被引用的孤立内存对象，定位泄漏点。
• 模块加载/卸载循环测试：反复加载和卸载驱动模块，对比前后内存使用量变化，判断是否存在泄漏。
• 压力测试与长时间运行：在高负载下长时间运行驱动，观察内存消耗趋势，发现间歇性泄漏。