Re: [TECH TOPIC] Implementing malloc

[Matthew Wilcox <willy@infradead.org>]

On Mon, Jun 29, 2026 at 06:07:43PM +0300, Dan Carpenter 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.
> > 
> > We'll also discuss the semantics of corner cases (fallibility, zero
> > sized allocations, overflowing allocations and very large allocations)
> > as well as out-of-bounds and use-after-free detection.
> 
> I'm not sure I understand.  You're saying that it's too complicated
> and then you're suggesting we introduce a new kind of allocation function
> as the fix.  It feels like the classic XKCD comic about standards:
> https://xkcd.com/927/

I'm not proposing introducing any kind of "new standard".  I'm proposing
that we implement the old standard from the 1970s which is "good enough"
for most allocations.

At some future point, I might suggest that we remove kvmalloc(), which
would reduce the number of APIs we support.  But that's not on the cards
for this year.

> Are we just collecting a wish list?

No, I'll have a concrete proposal by then.

> I wish that we would just acknowledge say that small allocations cannot
> fail.  We could add a BUILD_BUG_ON() in km/zalloc_obj() which ensures that
> it is only used for small allocations.  Then we could remove all the
> error handling from those.

That's part of the fallibility discussion I alluded to.  The problem
is that kzalloc_obj(x, GFP_NOWAIT) can fail, even for small objects.
And that is what the caller asked for!  So we have a tension there.

> With regards to use after frees, my impression is that the places which
> use caches are the worst affected and also where we do the worst at
> detecting them?  Does KASAN detect use after frees with kmem_cache and
> mempools?

I believe it does, but I'm not an expert.  My question in this instance
is really, "Are KASAN et al now good enough and widely deployed enough
that we don't need eg red zones or unmapped pages to catch these things".