Before this lecture, you should be comfortable with:

If any of these feel unfamiliar, go back to the earlier lectures in this
free embedded systems course before continuing.

Every time the kernel needs a small chunk of memory for a data structure, it could call
kmalloc(). But kmalloc() rounds your request up to the nearest
“power-of-two-ish” generic size bucket. If your structure is, say, 300 bytes, kmalloc will
hand you a 384-byte or 512-byte chunk from a generic pool shared by thousands of unrelated
allocations across the whole kernel. That wastes memory and gives you no control over
initialization, alignment, or debugging.

A custom slab cache solves this by asking the slab allocator (SLUB, in
current kernels) to manage a dedicated pool sized exactly for your structure. Every
object that comes out of that pool is the right size, can be pre-initialized with a
constructor, and can be tracked separately in /proc/slabinfo — which is
extremely useful when hunting memory leaks in your own driver.

Working with a custom slab cache always follows the same four-stage lifecycle. Understanding
this flow before looking at any single API makes everything else click into place.

Stages 2 and 3 typically repeat many times during the life of a driver — you allocate and
free objects over and over — while stages 1 and 4 happen exactly once, usually in your
module’s init and exit functions.

The entry point is a single call that registers a new named cache with the slab subsystem.
In modern kernel headers (<linux/slab.h>), the function looks like this:

struct kmem_cache *kmem_cache_create(const char *name,
                                      unsigned int size,
                                      unsigned int align,
                                      slab_flags_t flags,
                                      void (*ctor)(void *));

Important: this call must be made from normal process context (never from
an interrupt handler), and its return value must always be checked — a NULL
return means the cache could not be created, usually due to memory pressure at boot.

Once the cache exists, grabbing an object from it is a single call:

void *kmem_cache_alloc(struct kmem_cache *cache, gfp_t flags);

Just like kmalloc(), pass GFP_KERNEL when you’re allowed to sleep
(normal process context) and GFP_ATOMIC when you are inside an interrupt handler,
a spinlock-protected section, or any other atomic context where sleeping is forbidden.

When you’re finished with the object, return it to the cache instead of freeing it back to
the general page allocator:

void kmem_cache_free(struct kmem_cache *cache, void *object);

This is far cheaper than a full free-and-reallocate cycle through kfree()/
kmalloc(), because SLUB simply parks the object back on a per-CPU free list for
instant reuse.

void kmem_cache_destroy(struct kmem_cache *cache);

Call this exactly once, in your module’s exit path, and only after every object you
allocated from that cache has already been returned with kmem_cache_free().
Destroying a cache that still has outstanding objects will trigger a kernel warning and is a
classic source of memory-corruption bugs during module unload.

The flags parameter controls both debugging behavior and hardening. A few you
should know:

2026 kernel note: On production kernels, freelist pointers inside SLUB are
hardened using a per-cache random obfuscation value, and features such as random freelist
ordering and hardened usercopy checks are enabled by default on distro kernels to make
heap-exploitation techniques against slab caches significantly harder. You don’t need to
configure this yourself — it comes from CONFIG_SLAB_FREELIST_HARDENED and related
options — but it’s worth knowing it’s there when you read crash dumps.

Here is a small, original demo showing the full lifecycle for a fictional
struct pkt_buf used to represent an incoming packet buffer in a driver:

#include <linux/module.h>
#include <linux/slab.h>

struct pkt_buf {
    u8  data[64];
    u32 len;
};

static struct kmem_cache *pkt_cache;

static void pkt_ctor(void *obj)
{
    struct pkt_buf *p = obj;
    p->len = 0;
}

static int __init pktdemo_init(void)
{
    struct pkt_buf *pb;

    pkt_cache = kmem_cache_create("pkt_buf_cache",
                                  sizeof(struct pkt_buf),
                                  0,
                                  SLAB_HWCACHE_ALIGN,
                                  pkt_ctor);
    if (!pkt_cache)
        return -ENOMEM;

    pb = kmem_cache_alloc(pkt_cache, GFP_KERNEL);
    if (!pb) {
        kmem_cache_destroy(pkt_cache);
        return -ENOMEM;
    }

    pb->len = 42;
    pr_info("pktdemo: allocated buffer, len=%u\n", pb->len);

    kmem_cache_free(pkt_cache, pb);
    return 0;
}

static void __exit pktdemo_exit(void)
{
    kmem_cache_destroy(pkt_cache);
}

module_init(pktdemo_init);
module_exit(pktdemo_exit);
MODULE_LICENSE("GPL");

Build it with a standard out-of-tree Makefile, insert it with
insmod, and check dmesg for the printed log line. Then confirm the
cache appeared with:

$ cat /proc/slabinfo | grep pkt_buf_cache

Custom slab caches aren’t a niche feature — they power some of the busiest data structures
in the kernel:

Any structure that gets allocated and freed at very high frequency is a strong candidate
for its own dedicated cache instead of riding on generic kmalloc pools.

Troubleshooting tip: If rmmod hangs or logs a warning about a
cache still having active objects, add temporary pr_info() calls around every
kmem_cache_alloc()/kmem_cache_free() pair to find the leak before
removing them again.

Custom caches shine under high-frequency alloc/free churn because SLUB keeps a
per-CPU freelist, so most allocations never touch a lock at all. Choosing
SLAB_HWCACHE_ALIGN avoids false sharing between CPUs when multiple cores
touch neighboring objects concurrently — a subtle but real performance win on
multi-core embedded SoCs.

Slab caches are a favorite target in kernel exploitation research because heap-spray and
use-after-free bugs often manipulate freelist pointers. Modern kernels mitigate this with
freelist pointer hardening, random freelist ordering per cache, and hardened usercopy
boundary checks — all reasons to keep your target kernel updated rather than relying on
an old LTS branch for anything internet-facing.

Q1. What is a custom slab cache in the Linux kernel?
It’s a dedicated memory pool created with kmem_cache_create() for one specific
data structure, avoiding the size-rounding waste of generic kmalloc().

Q2. Is the SLAB allocator still used in modern kernels?
No. Both SLAB and SLOB were removed from mainline Linux starting with kernel 6.8; SLUB is now
the only slab allocator.

Q3. Can I call kmem_cache_create() from an interrupt handler?
No, it must always be called from process context.

Q4. What happens if I destroy a cache with objects still allocated?
The kernel logs a warning, and the leaked objects can cause memory corruption on module
reload.

Q5. When should GFP_ATOMIC be used instead of GFP_KERNEL?
Use GFP_ATOMIC whenever the allocation happens in a context that cannot sleep, such as an
interrupt handler or while holding a spinlock.

Q6. Does a custom slab cache improve performance?
Yes, for structures allocated and freed at high frequency, because SLUB reuses per-CPU
freelists instead of going through the general page allocator each time.

Q7. What does the constructor function do?
It runs automatically whenever a fresh object is carved out of newly added slab memory,
letting you set consistent default field values.

Q8. Where can I see my custom cache after creating it?
Check /proc/slabinfo — your cache name will appear as its own row with live
object counts.

A custom slab cache gives kernel and driver code precise, efficient control over memory
that would otherwise be wasted in generic kmalloc buckets. Once you’re comfortable with the
four-stage lifecycle — create, allocate, free, destroy — you’re ready to apply the same
pattern in your own drivers. This lecture is part of our ongoing free Linux kernel
development course and free Linux device drivers course; keep
following along for the next topic.