vault

kmalloc and the kmalloc Caches

15 min read

kmalloc and the kmalloc Caches

kmalloc() is the Linux kernel’s general-purpose allocator for small, physically contiguous objects — the kernel’s rough equivalent of userspace malloc(), but with a mandatory gfp_t flags argument that declares the allocation context (may it sleep? must it use DMA-able memory? is it accounted to a cgroup?). It is not a freestanding allocator: every kmalloc() call rounds the requested size up to one of a small fixed set of slab caches named kmalloc-8, kmalloc-16, … kmalloc-96, kmalloc-192, … kmalloc-8k (on a 4 KiB-page build), and serves the object from there (per mm/slab_common.c and include/linux/slab.h, as of Linux 6.12 LTS / 6.18 LTS). Requests larger than what a slab cache covers skip the slab layer entirely and go straight to the page allocator. On top of this baseline the kernel layers several security-hardening variants of the caches — accounted (kmalloc-cg-*), DMA (dma-kmalloc-*), reclaimable (kmalloc-rcl-*), and per-boot randomized copies (kmalloc-rnd-NN-*) — chosen automatically from the GFP flags and the caller’s code address. This note covers the kmalloc API and the cache machinery underneath it; the slab allocator that implements the caches is The Slab Allocator and SLUB, and the contrast with the virtually-contiguous allocator is kmalloc vs vmalloc.

Mental Model

Think of kmalloc as a size-bucketing front door onto the SLUB allocator. SLUB only knows how to manage caches of fixed-size objects (a cache of 256-byte slots, a cache of 1024-byte slots). kmalloc makes that usable for arbitrary sizes by maintaining a pre-built array of such caches at every power of two from 8 bytes up to twice the page size, plus two odd in-between sizes (96 and 192), and routing each request to the smallest cache whose object size is large enough. A 100-byte request is served from the 128-byte cache; a 200-byte request from the 256-byte cache. The slack between requested and served size is internal fragmentation — the price of having a small, cache-friendly set of bucket sizes rather than an exact-fit allocator.

flowchart TD
  CALL["kmalloc(size, gfp)"] --> CONST{"size a compile-time<br/>constant?"}
  CONST -->|yes| BIG{"size ><br/>KMALLOC_MAX_CACHE_SIZE<br/>(2 x PAGE_SIZE)?"}
  CONST -->|no| RUNTIME["__kmalloc_noprof()<br/>(runtime index lookup)"]
  BIG -->|yes| LARGE["__kmalloc_large_noprof()<br/>-> page allocator<br/>(alloc_pages), page-aligned"]
  BIG -->|no| IDX["kmalloc_index(size)<br/>round size up to a bucket"]
  IDX --> TYPE["kmalloc_type(gfp, caller)<br/>pick the cache *family*"]
  TYPE --> CACHE["kmalloc_caches[type][index]<br/>e.g. kmalloc-cg-256"]
  CACHE --> SLUB["SLUB: hand out one<br/>object slot from a slab"]
  RUNTIME --> IDX

How a kmalloc call reaches memory. What it shows: the request first splits on size — anything larger than KMALLOC_MAX_CACHE_SIZE (two pages, 8 KiB on a 4 KiB-page build) bypasses the slab layer and is satisfied directly by the page allocator as whole pages; everything smaller is mapped to a bucket index by kmalloc_index() and to a cache family by kmalloc_type() (normal, accounted, DMA, reclaimable, or a randomized copy), then served by SLUB. The insight to take: kmalloc is two allocators wearing one name — a slab front-end for small objects and a thin shim over the page allocator for large ones — and the GFP flags plus the call site jointly select which of several parallel cache arrays the object lands in.

How the Size Rounds Up to a Cache

The bucket selection is the function __kmalloc_index() in include/linux/slab.h. It is written as a cascade of if (size <= N) return idx; tests so that, for a compile-time-constant size (the overwhelmingly common case), the compiler folds the whole thing into a single constant — the macro kmalloc_index(s) is __kmalloc_index(s, true), and kmalloc_noprof() only takes this fast path when __builtin_constant_p(size) is true. The cascade (verbatim from the 6.12 source, identical in 6.18) is:

if (size <= KMALLOC_MIN_SIZE) return KMALLOC_SHIFT_LOW;   /* <= 8 -> idx 3 */
if (KMALLOC_MIN_SIZE <= 32 && size > 64 && size <= 96)  return 1;  /* the 96 bucket */
if (KMALLOC_MIN_SIZE <= 64 && size > 128 && size <= 192) return 2; /* the 192 bucket */
if (size <=    8) return 3;
if (size <=   16) return 4;
if (size <=   32) return 5;
if (size <=   64) return 6;
if (size <=  128) return 7;
if (size <=  256) return 8;
if (size <=  512) return 9;
if (size <= 1024) return 10;
if (size <= 2 * 1024) return 11;
/* ... continues up the table ... */

Read symbol by symbol: KMALLOC_MIN_SIZE is the smallest object the array supports — 1 << KMALLOC_SHIFT_LOW, and KMALLOC_SHIFT_LOW defaults to 3, so the floor is 8 bytes (a request for 1–8 bytes is served from kmalloc-8). The two special clauses produce the non-power-of-two buckets: a 65–96-byte request goes to index 1 (the kmalloc-96 cache) and a 129–192-byte request to index 2 (the kmalloc-192 cache). Why these two oddballs exist: without them, a 96-byte object would round up to kmalloc-128 and a 192-byte object to kmalloc-256, wasting 32 and 64 bytes respectively. The 96 and 192 caches roughly halve that waste for two extremely common object sizes, at the cost of two extra caches. Everything else is a clean power of two: index n (for n >= 3) holds objects in the range 2^(n-1)+1 .. 2^n.

The interesting structural detail is that indices 1 and 2 sit below index 3 in the array but hold larger objects (96 and 192 versus 8). The index is just an array slot, not a monotone size; the size→index mapping is what __kmalloc_index encodes, and the array kmalloc_caches[type][index] is what stores the actual struct kmem_cache * pointers.

The size ceiling and the large-allocation escape hatch

Three constants from slab.h bound the size space (definitions verbatim, 6.12/6.18):

#define KMALLOC_SHIFT_HIGH      (PAGE_SHIFT + 1)
#define KMALLOC_SHIFT_MAX       (MAX_PAGE_ORDER + PAGE_SHIFT)
#define KMALLOC_MAX_SIZE        (1UL << KMALLOC_SHIFT_MAX)
#define KMALLOC_MAX_CACHE_SIZE  (1UL << KMALLOC_SHIFT_HIGH)

KMALLOC_MAX_CACHE_SIZE is 2^(PAGE_SHIFT+1) — twice the page size, i.e. 8 KiB on a typical x86-64 build with 4 KiB pages. This is the largest object served from a slab cache; the in-source comment states the design directly: “SLUB directly allocates requests fitting in to an order-1 page (PAGE_SIZE*2). Larger requests are passed to the page allocator.” So the top slab-backed bucket is kmalloc-8k only because the page is 4 KiB; on a 64 KiB-page build (some arm64/ppc64 configs) the same formula puts the ceiling at 128 KiB. Pin the “8 KiB” figure to the 4 KiB-page case rather than treating it as universal.

Above that ceiling, kmalloc_noprof() takes the size > KMALLOC_MAX_CACHE_SIZE branch and calls __kmalloc_large_noprof(), which goes straight to the page allocator and returns page-aligned whole pages — no slab cache involved. The absolute ceiling is KMALLOC_MAX_SIZE = 2^(MAX_PAGE_ORDER + PAGE_SHIFT), the largest order the buddy allocator will hand out (on x86-64, MAX_PAGE_ORDER is 10, so 1024 pages = 4 MiB). The kernel documentation summarizes the practical guidance: “The maximal size of a chunk that can be allocated with kmalloc is limited. The actual limit depends on the hardware and the kernel configuration, but it is a good practice to use kmalloc for objects smaller than page size” (memory-allocation.rst, 6.12).

Uncertain

Verify: that the kmalloc_info[] table entries above 8 KiB (16k, 32k, 64k) do not correspond to instantiated slab caches on a 4 KiB-page x86-64 build. The table in mm/slab_common.c lists names up to kmalloc-64k, but create_kmalloc_caches() only instantiates indices KMALLOC_SHIFT_LOW .. KMALLOC_SHIFT_HIGH (3..13 on a 4 KiB build), so kmalloc-16k+ entries are names without backing caches; allocations of those sizes go via __kmalloc_large_noprof. Reason: inferred from the loop bound in create_kmalloc_caches(), not confirmed against a running /proc/slabinfo. To resolve: boot a 6.12 kernel and check grep kmalloc /proc/slabinfo for the highest kmalloc-N cache present. uncertain

Alignment guarantees

kmalloc returns addresses “aligned to at least ARCH_KMALLOC_MINALIGN bytes. For sizes which are a power of two, the alignment is also guaranteed to be at least the respective size. For other sizes, the alignment is guaranteed to be at least the largest power-of-two divisor of the size” (memory-allocation.rst). On x86-64, ARCH_KMALLOC_MINALIGN defaults to __alignof__(unsigned long long) = 8 bytes (it is raised to ARCH_DMA_MINALIGN if the architecture needs stronger DMA alignment). The power-of-two guarantee is why drivers can safely kmalloc a structure and rely on it being naturally aligned for DMA without an explicit alignment request.

The Cache Families: Normal, Accounted, DMA, Reclaimable, Randomized

kmalloc does not maintain a single array of caches — it maintains several parallel arrays, one per cache type, declared in slab.h as:

typedef struct kmem_cache * kmem_buckets[KMALLOC_SHIFT_HIGH + 1];
extern kmem_buckets kmalloc_caches[NR_KMALLOC_TYPES];

So kmalloc_caches is a two-dimensional array indexed by [type][size_index]. The enum kmalloc_cache_type lists the families (configuration-dependent; some collapse onto KMALLOC_NORMAL when their feature is compiled out):

  • KMALLOC_NORMAL — plain, unaccounted, non-DMA objects. Caches named kmalloc-8 … kmalloc-8k (the names come from INIT_KMALLOC_INFO in mm/slab_common.c).
  • KMALLOC_CGROUP — objects that are charged to a memory cgroup (allocated with __GFP_ACCOUNT). Present only when CONFIG_MEMCG is enabled. Caches named kmalloc-cg-N, created with the SLAB_ACCOUNT flag. The in-source comment is explicit: “KMALLOC_NORMAL can contain only unaccounted objects whereas KMALLOC_CGROUP is for accounted but unreclaimable and non-dma objects.” Separating accounted from unaccounted objects keeps a cgroup’s memory accounting precise — an unaccounted normal object can never accidentally share a slab page with an accounted one.
  • KMALLOC_DMA — objects that must live in the low DMA zone (allocated with __GFP_DMA). Present only when CONFIG_ZONE_DMA. Caches named dma-kmalloc-N, created with SLAB_CACHE_DMA.
  • KMALLOC_RECLAIM — reclaimable objects (allocated with __GFP_RECLAIMABLE). Caches named kmalloc-rcl-N, created with SLAB_RECLAIM_ACCOUNT, which tells reclaim these slabs can be shrunk under pressure.
  • KMALLOC_RANDOM_START .. KMALLOC_RANDOM_END — the per-boot randomized copies, the hardening feature covered below. Caches named kmalloc-rnd-01-N … kmalloc-rnd-15-N.

The function kmalloc_type(gfp_t flags, unsigned long caller) chooses the family from the GFP flags. Its fast path is a single test: if none of the “not normal” bits (__GFP_RECLAIMABLE, __GFP_DMA, __GFP_ACCOUNT) are set, the allocation is normal. Otherwise the flags are ranked in priority order — DMA, then reclaimable, then accounted — and the corresponding family is returned. This is why a GFP_KERNEL | __GFP_ACCOUNT allocation lands in kmalloc-cg-* while a bare GFP_KERNEL allocation lands in kmalloc-* (or a randomized copy of it).

Hardening: Randomized Caches and Separated Buckets

These are two distinct security features, both aimed at the same attacker technique — heap spraying, where an exploit allocates many objects of a controlled size to position attacker-controlled data adjacent to a victim object (e.g. to corrupt it via an overflow, or to reclaim its freed slot in a use-after-free). Conflating them is a common error.

CONFIG_RANDOM_KMALLOC_CACHES spreads normal kmalloc allocations across 16 parallel copies of each size cache, choosing the copy by hashing the caller’s code address against a per-boot random seed. From the Kconfig help text: “A hardening feature that creates multiple copies of slab caches for normal kmalloc allocation and makes kmalloc randomly pick one based on code address, which makes the attackers more difficult to spray vulnerable memory objects on the heap for the purpose of exploiting memory vulnerabilities. Currently the number of copies is set to 16…”. The mechanism is the kmalloc_type() fast path:

return KMALLOC_RANDOM_START + hash_64(caller ^ random_kmalloc_seed,
                                      ilog2(RANDOM_KMALLOC_CACHES_NR + 1));

Walking the symbols: caller is the return address of the kmalloc call site (captured via _RET_IP_); random_kmalloc_seed is a u64 set once at boot by random_kmalloc_seed = get_random_u64() in create_kmalloc_caches(); hash_64 mixes them into a bucket number in [0, 15]. The consequence is precise and worth stating exactly: a given call site maps to a stable bucket within one boot, but to an unpredictable bucket across boots, and different call sites land in different buckets. An attacker can no longer reliably co-locate objects allocated from their call site (e.g. a sendmsg buffer) with a victim object allocated from a different call site, because the two almost certainly hash to different caches — and the attacker cannot precompute which, since the seed is secret and per-boot. The number reconciliation: the constant RANDOM_KMALLOC_CACHES_NR is 15 (the count of extra named copies, kmalloc-rnd-01 … kmalloc-rnd-15), and together with the base KMALLOC_NORMAL slot that gives the 16 the Kconfig text advertises. The randomized copies are created with SLAB_NO_MERGE so SLUB will not merge them back together and defeat the separation.

CONFIG_SLAB_BUCKETS is a different lever. Rather than randomizing all normal allocations, it lets specific user-controlled call sites allocate from an explicitly isolated set of buckets. Its Kconfig rationale: “Kernel heap attacks frequently depend on being able to create specifically-sized allocations with user-controlled contents that will be allocated into the same kmalloc bucket as a target object. To avoid sharing these allocation buckets, provide an explicitly separated set of buckets to be used for user-controlled allocations.” It defaults to the value of CONFIG_SLAB_FREELIST_HARDENED and is plumbed through the kmem_buckets parameter that __kmalloc_node_noprof and friends accept. So RANDOM_KMALLOC_CACHES blindly scatters every normal allocation by call site, whereas SLAB_BUCKETS surgically isolates the call sites known to carry attacker-controlled payloads (memdup_user, message buffers). They compose.

The introduction timeline, pinned by bisecting adjacent release tags in the source tree: the kmalloc-cg-* accounted-cache split (KMALLOC_CGROUP) first appears in include/linux/slab.h at v5.14 (absent in v5.13); CONFIG_RANDOM_KMALLOC_CACHES first appears in mm/Kconfig at v6.6 (absent in v6.5); and CONFIG_SLAB_BUCKETS first appears at v6.11 (absent in v6.10). All three are present and have the behavior described above in 6.12 LTS and 6.18 LTS.

When kmalloc, and the kvmalloc Escape Hatch

kmalloc is the default choice for kernel objects smaller than a page. Use kzalloc() to get zeroed memory (it is kmalloc with __GFP_ZERO), kmalloc_array() / kcalloc() for arrays (they reject size-overflow), and krealloc() to resize. The kernel’s own one-line guidance: “very likely you should use kzalloc(<size>, GFP_KERNEL)” (memory-allocation.rst).

If you are unsure whether the size might exceed the kmalloc ceiling — for example a buffer whose size comes from userspace — reach for kvmalloc(), which tries kmalloc first and falls back to vmalloc on failure, returning possibly non-contiguous memory freed with kvfree(). The full mechanics of that fallback — the GFP-flag adjustments, the size <= PAGE_SIZE short-circuit, and why GFP_ATOMIC/GFP_NOWAIT are forbidden — are the subject of kmalloc vs vmalloc; here it is enough to know kvmalloc exists as the “I don’t know how big this is” door.

Failure Modes and Common Misunderstandings

  • GFP_KERNEL in atomic context. GFP_KERNEL “may sleep” (it permits direct reclaim). Calling kmalloc(size, GFP_KERNEL) from an interrupt handler, while holding a spinlock, or in any non-preemptible region is a classic bug — use GFP_ATOMIC (which “may use emergency pools” but will not sleep) or GFP_NOWAIT there. See GFP Flags and Allocation Contexts.
  • Assuming exact-size allocation. kmalloc(100, …) gives you a 128-byte object. Writing past byte 100 up to 128 will not be caught at runtime in a normal build — but it will trip KASAN, FORTIFY_SOURCE, or UBSAN_BOUNDS in a debug build, because those track the requested size, not the bucket size. Use kmalloc_size_roundup() if you legitimately want to use the slack.
  • Expecting large contiguous allocations to succeed reliably. A kmalloc above one page asks the buddy allocator for a high-order, physically-contiguous run, which can fail under fragmentation even when plenty of memory is free. If you do not actually need physical contiguity, use vmalloc/kvmalloc instead — this is exactly the trade-off in kmalloc vs vmalloc.
  • Treating dma-kmalloc-* as always present. The DMA caches exist only with CONFIG_ZONE_DMA; on a kernel without it, KMALLOC_DMA aliases KMALLOC_NORMAL. Likewise kmalloc-cg-* requires CONFIG_MEMCG.

Alternatives and When to Choose Them

  • A dedicated kmem_cache (Kmem Caches and Object Slabs): if you allocate many objects of one fixed type (a struct dentry, a task_struct), create your own named cache with kmem_cache_create(). You get a constructor, exact sizing (no power-of-two rounding waste), per-cache statistics in /proc/slabinfo, and better cache locality. kmalloc is this mechanism with a generic set of sizes.
  • alloc_pages() / the page allocator (The Buddy Allocator): if you need whole pages, or more than KMALLOC_MAX_CACHE_SIZE, and want to manage them yourself. kmalloc of a large size already does this for you, but going direct gives you the struct page/folio and control over the order.
  • vmalloc / kvmalloc (vmalloc and Virtually Contiguous Memory, kmalloc vs vmalloc): for large allocations where physical contiguity is unnecessary.

For contrast with userspace allocators that solve the same size-bucketing problem a layer up — The pymalloc Allocator (CPython’s arena/pool/block scheme) and the Go Memory Allocator (TCMalloc-style size classes) both bucket small objects by size class much as kmalloc does, but in userspace and without the GFP-context or DMA/cgroup dimensions the kernel must juggle.

Production Notes

The randomized caches show up in /proc/slabinfo as many kmalloc-rnd-NN-N lines, which can surprise operators reading slab usage — total kmalloc footprint is spread across the copies. Memory-cgroup-accounted kernel allocations appear as kmalloc-cg-*; their growth is what a container’s memory.current reflects for slab-backed kernel state (The Memory Cgroup memcg). When debugging a suspected slab overflow, enabling CONFIG_SLUB_DEBUG with slab_debug= adds red-zoning and poisoning to specific caches (e.g. slab_debug=,kmalloc-256), and the kmalloc_info[] table exists partly so that boot-time slab_debug=,kmalloc-xx works before the caches are created.

See Also

Graph View

Backlinks