Re: [TECH TOPIC] Implementing malloc

[Dan Carpenter <error27@gmail.com>]

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/

Are we just collecting a wish list?

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.

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?

regards,
dan carpenter