Re: [TECH TOPIC] Implementing malloc

On July 9, 2026 10:11:21 AM PDT, Matthew Wilcox <[email protected]> wrote:
>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?
>

If Rust can't deal with different memory allocators then Rust in Linux was a huge mistake that we should rip out right now before it is too late.