Re: [TECH TOPIC] Implementing malloc

On June 29, 2026 8:07:43 AM PDT, Dan Carpenter <[email protected]> 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/
>
>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
>
>
>

It's like memory management in a kernel is difficult or something...