Re: [TECH TOPIC] Implementing malloc

On Thu, Jul 09, 2026 at 10:30:53AM -0700, H. Peter Anvin wrote:
> 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.
> 

Um, rust already handles the GFP flags just fine for the allocators.
What is missing from what is there today?

thanks,

greg k-h