What You Will Learn

Prerequisites

Why Linux Kernel Memory Allocation Is Different From malloc()

In user-space programming, you call malloc() and mostly stop thinking about it. Inside the kernel, that luxury disappears. Kernel memory is a limited, shared resource that every driver, filesystem, and subsystem competes for, and there is no safety net if you get it wrong — a bad allocation can bring the whole machine down. This is exactly why the Linux kernel exposes multiple, purpose-built memory allocation APIs instead of a single generic one. Each API is optimized for a different pattern of usage: small short-lived buffers, large virtually-contiguous regions, or memory that must be physically contiguous for hardware access.

The Slab Allocator: kmalloc(), kzalloc(), and kcalloc()

For the vast majority of kernel modules and drivers, the slab allocator family is your default choice. It is fast, it is efficient for small chunks under one page in size, and it guarantees physically contiguous memory — something many drivers require for hardware buffers.

#include <linux/slab.h>

struct my_device_state *state;

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

/* ... use state ... */

kfree(state);

kzalloc() is simply kmalloc() with the memory pre-zeroed, which avoids a whole class of bugs caused by reading uninitialized kernel memory. For arrays, kcalloc() performs the same job while safely checking for integer overflow in the size calculation, which kmalloc() alone does not do.

Resource-Managed Allocation: devm_kzalloc() for Device Drivers

Modern driver code, especially anything written against the platform driver or I2C/SPI frameworks, tends to prefer devm_kzalloc() over plain kzalloc(). The “devm” prefix stands for device-managed: the allocation is tied to the lifetime of the struct device, and the kernel automatically frees it when the driver is unbound or the probe fails partway through.

#include <linux/device.h>

static int my_probe(struct platform_device *pdev)
{
        struct my_priv *priv;

        priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
        if (!priv)
                return -ENOMEM;

        platform_set_drvdata(pdev, priv);
        return 0;
}

This removes an entire category of memory-leak bugs from driver error-handling paths, which is why most driver subsystems recommend it as the default for probe()-time allocations.

The Page Allocator: __get_free_pages() and alloc_pages()

When you need memory in whole-page units — for example, building a custom buffer pool or working close to the memory management subsystem itself — the page allocator is the right layer. It hands out physically contiguous memory in power-of-two page counts and is what the slab allocator itself is built on top of.

#include <linux/gfp.h>

unsigned long addr;

addr = __get_free_pages(GFP_KERNEL, 2); /* 2^2 = 4 pages */
if (!addr)
        return -ENOMEM;

/* ... use addr ... */

free_pages(addr, 2);

Virtually Contiguous Memory: vmalloc() and kvmalloc()

Sometimes you need a large buffer — several megabytes — and physical contiguity does not matter because the CPU or DMA engine will access it through page tables anyway. That is exactly what vmalloc() is for: it stitches together scattered physical pages into one virtually contiguous range.

The catch with vmalloc() is that it is noticeably slower than kmalloc() because of the page-table setup involved, so it should not be your first choice for small buffers. This is where kvmalloc() shines: it tries the fast slab-allocator path first and only falls back to vmalloc() if the request is too large or memory is fragmented, giving you the best of both worlds without writing that fallback logic yourself.

#include <linux/mm.h>

void *buf = kvmalloc(large_size, GFP_KERNEL);
if (!buf)
        return -ENOMEM;

/* ... use buf ... */

kvfree(buf);

GFP Flags Explained: Atomic Context vs Process Context

Every kernel memory allocation call takes a GFP (Get Free Pages) flag that tells the kernel how aggressively it is allowed to look for memory, and — critically — whether it is allowed to sleep while doing so.

Context	Correct Flag	Can It Sleep?
Interrupt handler / atomic context / spinlock held	GFP_ATOMIC	No
Process context, safe to block (e.g. probe(), ioctl())	GFP_KERNEL	Yes
Memory destined for userspace mapping	GFP_USER / GFP_HIGHUSER	Yes

The golden rule of Linux kernel memory allocation is simple: if you are not 100% certain sleeping is safe, use GFP_ATOMIC. If you know you are in ordinary process context, GFP_KERNEL is almost always correct and lets the kernel reclaim memory intelligently under pressure.

Visual Decision Flow: Which Allocation API Should You Use?

Comparison Table: kmalloc vs vmalloc vs Page Allocator vs devm_kzalloc

API	Physically Contiguous?	Typical Size	Best For
kmalloc / kzalloc	Yes	< 1 page	General-purpose module/driver data
devm_kzalloc	Yes	< 1 page	Driver probe()/init auto-cleanup
__get_free_pages / alloc_pages	Yes	Whole pages	Buffer pools, low-level MM work
vmalloc / vzalloc	No	Large (MBs)	Large software-only buffers
kvmalloc	Sometimes	Unknown / variable	When you’re unsure of runtime size

Real-World Use Case: Allocating Buffers in a Character Driver

Imagine you are writing a simple character driver that needs a small per-open buffer for read/write operations. Since the buffer is small, allocated during a device open() (process context, safe to sleep), and needs physical contiguity for a potential future DMA upgrade, kzalloc() with GFP_KERNEL is the textbook-correct choice. If that same driver later needs a large capture buffer whose size is only known at runtime — say, from a userspace ioctl() — kvmalloc() becomes the safer bet because it gracefully degrades instead of failing outright when the slab allocator cannot satisfy a large contiguous request.

Common Mistakes and Troubleshooting

Best Practices for Kernel Memory Allocation

Performance Considerations

The slab allocator is optimized for speed and low overhead on small, frequent allocations, which is why it should always be your default. vmalloc() carries real overhead from page-table manipulation, so using it for small, frequent allocations is a common and avoidable performance mistake. If your driver allocates and frees memory on a hot path (for example, per-packet or per-interrupt), consider pre-allocating a pool once and reusing it rather than calling into any allocator repeatedly.

Security Considerations

Always zero memory that will ever be copied to or exposed to userspace — kzalloc() and kvzalloc() exist specifically to prevent leaking stale kernel data through uninitialized buffers. When an allocation is triggered by an untrusted userspace request, consider using accounted allocation flags so a malicious or buggy process cannot exhaust kernel memory and destabilize the whole system.

Summary and Key Takeaways

Conclusion

Choosing the correct linux kernel memory allocation API is not about memorizing a list — it is about asking three quick questions every time: how big is this allocation, can I sleep while making it, and does it need to be physically contiguous? Once those three answers are clear, the right API almost picks itself. Keep this guide as a quick reference the next time you sit down to write a kernel module or device driver, and you will avoid the vast majority of memory-related bugs that trip up newcomers to Linux kernel development.

Frequently Asked Questions