Re: [TECH TOPIC] Implementing malloc

["Vlastimil Babka (SUSE)" <vbabka@kernel.org>]

On 6/29/26 17:31, Matthew Wilcox wrote:
> On Mon, Jun 29, 2026 at 06:07:43PM +0300, Dan Carpenter wrote:
>> 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.

Indeed. Also userspace malloc() isn't "cannot fail" either?

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

My understanding (also not KASAN expert, but through the slab interactions
learned some stuff) is that HW TAGS based KASAN is enough for Android
production, but the overhead is not negligible and the HW support isn't
ubiquitous.

"Classic" KASAN is powerful but overhead is large and needs a recompile. Not
something suitable for production.

Stuff like poisoning and slab_debug or debug_pagealloc (unmapping) is weaker
(less likely to catch a culprit), also have overhead, but their advantage is
they can be always compiled-in in a generic distro kernel and you can tell a
user to enable it on boot as part of chasing a bug seen in production,
without using a special debug kernel.

So I'd say everything above has its use case and its not time to drop
something in favor of something else.