Re: [TECH TOPIC] Implementing malloc

[Kees Cook <kees@kernel.org>]

On Mon, Jun 29, 2026 at 03:29:42PM +0100, Matthew Wilcox wrote:
> malloc() is a standard part of the C library.  Yet we force new Linux
> programmers to learn the difference between vmalloc(), kmalloc() and
> kvmalloc().  They even have to acquire an understanding of the difference
> between GFP_KERNEL and GFP_ATOMIC.  If they are particularly unlucky,
> they may have to understand other combinations of GFP flags.
> 
> This topic proposes that we should implement malloc() and calloc().
> Various options will be discussed, their increasing implementation
> complexity corresponding to utility in a greater range of situations.
> This will also benefit Rust as we can use the same infrastructure to
> implement std::alloc.

No surprise, but I strongly disagree with this. Those APIs are flawed
and we shouldn't emulate them. This is why we just removed strncpy(),
for example.

Allocations need to be type-based, not size-based. When we force people
to reduce it to just byte count tons of metadata that can be used by
both the kernel and the compiler is lost. The size is a by-product of
"what do you need space for?" "I need X many Foo objects" or "I need
Bar with Z many trailing Baz objects" or even "I need a plane of pixels
X by Y". The uncommon case is "I need X many bytes from this stream".

-Kees

-- 
Kees Cook