Re: [TECH TOPIC] Implementing malloc

On 2026-06-29 08:31, Matthew Wilcox wrote:
> 
> 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.
> 

... and which has 60 years of computer science textbooks talking about all the
problems with it.

malloc() models - although doesn't require - the natural API of an arena
allocator operating on a fixed-sized memory pool. Only hard failures are
recognized.

The kernel is a very special environment, and nothing is more special about it
than memory. The interface we have for "most allocations" is
kmalloc(..., GFP_KERNEL), which already there shows the need for controlling
error handling in the kernel environment.

We have all these APIs because they have different fragmentation, performance,
and failure attributes, and we need that if we want the Linux kernel to remain
lean and performant.

> 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.

Touché.

>> 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".

No. Nor will it be, because the overhead is much too high.

	-hpa