[TECH TOPIC] Implementing malloc

[TECH TOPIC] Implementing malloc

[Matthew Wilcox]

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.

Re: [TECH TOPIC] Implementing malloc

[Dan Carpenter]

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

Re: [TECH TOPIC] Implementing malloc

[H. Peter Anvin]

On June 29, 2026 8:07:43 AM PDT, Dan Carpenter <error27@gmail.com> 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...

Re: [TECH TOPIC] Implementing malloc

[Matthew Wilcox]

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

Re: [TECH TOPIC] Implementing malloc

[Vlastimil Babka (SUSE)]

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.

Re: [TECH TOPIC] Implementing malloc

[H. Peter Anvin]

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

Re: [TECH TOPIC] Implementing malloc

[Alexey Dobriyan]

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

I'd say no.

* they return void*, not T*,

* individual kmemcaches should be used more for better debugging
  experience

	malexey()

Re: [TECH TOPIC] Implementing malloc

[H. Peter Anvin]

On 2026-06-29 07:29, 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.

You *NEED* to understand that if you are going to program kernel code. There
probably isn't anything more important, *really*.

The kernel is a memory manager first, a scheduler second, all else is commentary.

	-hpa

Re: [TECH TOPIC] Implementing malloc

[Matthew Wilcox]

On Mon, Jun 29, 2026 at 09:48:25AM -0700, H. Peter Anvin wrote:
> On 2026-06-29 07:29, 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.
> 
> You *NEED* to understand that if you are going to program kernel code. There
> probably isn't anything more important, *really*.

There's a lot of kernel code where that's true.  malloc() is not The One
True Interface to allocate memory, and at this point I'm not advocating
for removing any of the existing ones.

But we do have code which just needs to allocate "some memory", doesn't
have any particularly weird restrictions, and where usability is more
important than "pedal to the metal".  An example might be something
like zlib.  It needs to allocate some temporary memory, and why have to

#ifdef __KERNEL__
#define malloc(x)	kvmalloc(x, GFP_KERNEL)
#endif

> The kernel is a memory manager first, a scheduler second, all else is commentary.

Some filesystem people might have things to say about that.  But
increasingly the kernel is just the runtime for eBPF programs ;-)

Re: [TECH TOPIC] Implementing malloc

[H. Peter Anvin]

On June 29, 2026 11:19:20 AM PDT, Matthew Wilcox <willy@infradead.org> wrote:
>On Mon, Jun 29, 2026 at 09:48:25AM -0700, H. Peter Anvin wrote:
>> On 2026-06-29 07:29, 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.
>> 
>> You *NEED* to understand that if you are going to program kernel code. There
>> probably isn't anything more important, *really*.
>
>There's a lot of kernel code where that's true.  malloc() is not The One
>True Interface to allocate memory, and at this point I'm not advocating
>for removing any of the existing ones.
>
>But we do have code which just needs to allocate "some memory", doesn't
>have any particularly weird restrictions, and where usability is more
>important than "pedal to the metal".  An example might be something
>like zlib.  It needs to allocate some temporary memory, and why have to
>
>#ifdef __KERNEL__
>#define malloc(x)	kvmalloc(x, GFP_KERNEL)
>#endif
>
>> The kernel is a memory manager first, a scheduler second, all else is commentary.
>
>Some filesystem people might have things to say about that.  But
>increasingly the kernel is just the runtime for eBPF programs ;-)
>

You *do* know that zlib gets passed an allocation function to it, and for good reason, right?

Re: [TECH TOPIC] Implementing malloc

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 624 bytes --]

On Mon, Jun 29, 2026 at 07:19:20PM +0100, Matthew Wilcox wrote:

> But we do have code which just needs to allocate "some memory", doesn't
> have any particularly weird restrictions, and where usability is more
> important than "pedal to the metal".  An example might be something
> like zlib.  It needs to allocate some temporary memory, and why have to

Or drivers just allocating some driver data.  TBH kzalloc() kind of ends
up being that function a lot of the time, I'm not convinced that a high
proportion of the kzalloc(x, GFP_KERNEL) calls out there are the result
of a deep consideration of which allocator to use.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [TECH TOPIC] Implementing malloc

[Vlastimil Babka (SUSE)]

On 6/29/26 8:29 PM, Mark Brown wrote:
> On Mon, Jun 29, 2026 at 07:19:20PM +0100, Matthew Wilcox wrote:
> 
>> But we do have code which just needs to allocate "some memory", doesn't
>> have any particularly weird restrictions, and where usability is more
>> important than "pedal to the metal".  An example might be something
>> like zlib.  It needs to allocate some temporary memory, and why have to
> 
> Or drivers just allocating some driver data.  TBH kzalloc() kind of ends
> up being that function a lot of the time, I'm not convinced that a high
> proportion of the kzalloc(x, GFP_KERNEL) calls out there are the result
> of a deep consideration of which allocator to use.

Actually "x = kzalloc_obj(*x);" these days, with the GFP_KERNEL implicit.

Re: [TECH TOPIC] Implementing malloc

[Steven Rostedt]

On Mon, 29 Jun 2026 19:19:20 +0100
Matthew Wilcox <willy@infradead.org> wrote:

> #ifdef __KERNEL__
> #define malloc(x)	kvmalloc(x, GFP_KERNEL)
> #endif

If anything, add a might_sleep() to that, so it triggers a very bad warning
if called in any context that does not allow a schedule.

-- Steve