Re: [TECH TOPIC] Implementing malloc

[Matthew Wilcox <willy@infradead.org>]

On Thu, Jul 09, 2026 at 09:58:37AM -0700, Kees Cook wrote:
> 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".

I agree that many memory allocations benefit from providing more semantic
information to both the compiler and the runtime, as you suggest.
What I don't think we benefit from is "And you have to pass this magic
GFP_KERNEL argument too.  Unless it's GFP_ATOMIC or something".

Maybe I'm confusing / distracting by framing this around "Hey, malloc()
is a great interface and we should implement it" when what I really mean
is "GFP flags suck and we should strive to redesign the kernel so that
the vast majority of allocations don't need them".

I'm happy to rephrase the proposal in that way if it'll help.  I thought
that malloc() would be the right vehicle for getting my point across,
but it seems to be a distraction.

What I really don't want to see is a whole pile of Rust changes to
accommodate having to pass GFP flags to memory allocations.  Would that
be a better vehicle for the discussion?