3、内存分配与释放API：kmalloc/kfree、vmalloc/vfree、kmem_cache_alloc/kmem_cache_free、get_free_page/free_page

内存分配，是内核开发里最基础也最容易翻车的地方。我见过太多新手，甚至一些老手，在API选择上栽跟头。说白了，这四种分配方式各有各的脾气，用错了轻则性能下降，重则系统崩溃。

今天咱们就把这四组API掰开揉碎了讲清楚。你想想看，内核里跑着成千上万的进程，内存就那么大，怎么分才合理？这就是我们要解决的问题。

4.1 kmalloc/kfree：最常用的“小件”分配器

kmalloc 是我个人用得最多的API。它分配的是物理连续的内存，而且速度极快。为什么快？因为它背后是 slab 分配器在干活。

来看个实际例子：

#include <linux/slab.h>

struct my_device {
    int id;
    char name[32];
    void __iomem *regs;
};

struct my_device *dev;

// 分配内存
dev = kmalloc(sizeof(*dev), GFP_KERNEL);
if (!dev) {
    pr_err("Failed to allocate my_device\n");
    return -ENOMEM;
}

// 使用...
dev->id = 42;
snprintf(dev->name, sizeof(dev->name), "device_%d", dev->id);

// 释放
kfree(dev);

嗯，这里要注意 GFP_KERNEL 这个标志。它表示分配时可以睡眠，所以不能在中断上下文使用。我在项目中遇到过有人在中断里用 GFP_KERNEL，结果系统直接死锁。正确的做法是用 GFP_ATOMIC。

4.2 vmalloc/vfree：大块内存的救星

vmalloc 分配的是虚拟地址连续、物理地址不连续的内存。说白了，它适合分配大块内存（比如几MB甚至更大）。

为什么需要它？因为物理内存碎片化严重时，kmalloc 可能分配不到大块连续物理内存。这时候 vmalloc 就派上用场了。

#include <linux/vmalloc.h>

void *large_buf;

// 分配 1MB 内存
large_buf = vmalloc(1024 * 1024);
if (!large_buf) {
    pr_err("Failed to allocate 1MB buffer\n");
    return -ENOMEM;
}

// 使用...
memset(large_buf, 0, 1024 * 1024);

// 释放
vfree(large_buf);

4.3 kmem_cache_alloc/kmem_cache_free：为“同款对象”量身定制

这个API是我最喜欢的。它专门为固定大小的对象分配内存，比如你频繁创建和销毁的 struct inode 或 struct dentry。

为什么快？因为 slab 分配器提前准备好了大小相同的对象，分配时直接从缓存里拿，释放时放回去。没有碎片，没有复杂的合并操作。

#include <linux/slab.h>

struct my_object {
    int data;
    struct list_head list;
};

static struct kmem_cache *my_cache;

// 创建缓存
my_cache = kmem_cache_create("my_object_cache",
                             sizeof(struct my_object),
                             0,  // 对齐，0表示默认
                             SLAB_HWCACHE_ALIGN,  // 按硬件缓存行对齐
                             NULL);  // 构造函数，通常为NULL
if (!my_cache) {
    pr_err("Failed to create slab cache\n");
    return -ENOMEM;
}

// 分配对象
struct my_object *obj = kmem_cache_alloc(my_cache, GFP_KERNEL);
if (!obj) {
    pr_err("Failed to allocate object\n");
    return -ENOMEM;
}

// 使用...
obj->data = 100;
INIT_LIST_HEAD(&obj->list);

// 释放对象
kmem_cache_free(my_cache, obj);

// 销毁缓存（模块卸载时）
kmem_cache_destroy(my_cache);

你看，kmem_cache_alloc 比 kmalloc 快将近3倍。这就是为什么内核里大量使用 slab 缓存的原因。

4.4 get_free_page/free_page：最底层的页分配器

这是最接近硬件的分配方式。它直接操作伙伴系统，分配的是物理连续的页框。一页通常是4KB。

说实话，我平时很少直接用这个API。除非你在写底层驱动，或者需要操作页表，否则用 kmalloc 就够了。

#include <linux/gfp.h>

unsigned long page_addr;

// 分配一页
page_addr = __get_free_page(GFP_KERNEL);
if (!page_addr) {
    pr_err("Failed to allocate page\n");
    return -ENOMEM;
}

// 获取页的虚拟地址
void *page_virt = (void *)page_addr;

// 使用...
memset(page_virt, 0, PAGE_SIZE);

// 释放
free_page(page_addr);

4.5 如何选择？一张图说清楚

下面这张图是我自己总结的决策流程，每次写代码前我都会过一遍：

4.6 避坑总结

最后，我把自己踩过的坑整理一下：

• API 混用：kmalloc 分配的内存用 vfree 释放？内核直接 panic。我见过有人这么干，结果 debug 了一周。
• 忘记检查返回值：kmalloc 可能返回 NULL。别偷懒，每次都要检查。
• GFP 标志用错：中断上下文用 GFP_KERNEL？等着死锁吧。
• 内存泄漏：分配了不释放，或者释放了还继续用（use-after-free）。
• 越界访问：分配了 100 字节，写了 200 字节。这种 bug 最难查。

好了，这四种API就讲到这里。记住：选对API，你的代码就成功了一半。剩下的，就是细心和测试了。

---