[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

Re: [TECH TOPIC] Implementing malloc

[Kees Cook]

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.

No surprise, but I strongly disagree with this. Those APIs are flawed
and we shouldn't emulate them. This is why we just removed strncpy(),
for example.

Allocations need to be type-based, not size-based. When we force people
to reduce it to just byte count tons of metadata that can be used by
both the kernel and the compiler is lost. The size is a by-product of
"what do you need space for?" "I need X many Foo objects" or "I need
Bar with Z many trailing Baz objects" or even "I need a plane of pixels
X by Y". The uncommon case is "I need X many bytes from this stream".

-Kees

-- 
Kees Cook

Re: [TECH TOPIC] Implementing malloc

[Matthew Wilcox]

On Thu, Jul 09, 2026 at 09:58:37AM -0700, Kees Cook 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.
> 
> No surprise, but I strongly disagree with this. Those APIs are flawed
> and we shouldn't emulate them. This is why we just removed strncpy(),
> for example.
> 
> Allocations need to be type-based, not size-based. When we force people
> to reduce it to just byte count tons of metadata that can be used by
> both the kernel and the compiler is lost. The size is a by-product of
> "what do you need space for?" "I need X many Foo objects" or "I need
> Bar with Z many trailing Baz objects" or even "I need a plane of pixels
> X by Y". The uncommon case is "I need X many bytes from this stream".

I agree that many memory allocations benefit from providing more semantic
information to both the compiler and the runtime, as you suggest.
What I don't think we benefit from is "And you have to pass this magic
GFP_KERNEL argument too.  Unless it's GFP_ATOMIC or something".

Maybe I'm confusing / distracting by framing this around "Hey, malloc()
is a great interface and we should implement it" when what I really mean
is "GFP flags suck and we should strive to redesign the kernel so that
the vast majority of allocations don't need them".

I'm happy to rephrase the proposal in that way if it'll help.  I thought
that malloc() would be the right vehicle for getting my point across,
but it seems to be a distraction.

What I really don't want to see is a whole pile of Rust changes to
accommodate having to pass GFP flags to memory allocations.  Would that
be a better vehicle for the discussion?

Re: [TECH TOPIC] Implementing malloc

[H. Peter Anvin]

On July 9, 2026 10:11:21 AM PDT, Matthew Wilcox <willy@infradead.org> wrote:
>On Thu, Jul 09, 2026 at 09:58:37AM -0700, Kees Cook 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.
>> 
>> No surprise, but I strongly disagree with this. Those APIs are flawed
>> and we shouldn't emulate them. This is why we just removed strncpy(),
>> for example.
>> 
>> Allocations need to be type-based, not size-based. When we force people
>> to reduce it to just byte count tons of metadata that can be used by
>> both the kernel and the compiler is lost. The size is a by-product of
>> "what do you need space for?" "I need X many Foo objects" or "I need
>> Bar with Z many trailing Baz objects" or even "I need a plane of pixels
>> X by Y". The uncommon case is "I need X many bytes from this stream".
>
>I agree that many memory allocations benefit from providing more semantic
>information to both the compiler and the runtime, as you suggest.
>What I don't think we benefit from is "And you have to pass this magic
>GFP_KERNEL argument too.  Unless it's GFP_ATOMIC or something".
>
>Maybe I'm confusing / distracting by framing this around "Hey, malloc()
>is a great interface and we should implement it" when what I really mean
>is "GFP flags suck and we should strive to redesign the kernel so that
>the vast majority of allocations don't need them".
>
>I'm happy to rephrase the proposal in that way if it'll help.  I thought
>that malloc() would be the right vehicle for getting my point across,
>but it seems to be a distraction.
>
>What I really don't want to see is a whole pile of Rust changes to
>accommodate having to pass GFP flags to memory allocations.  Would that
>be a better vehicle for the discussion?
>

If Rust can't deal with different memory allocators then Rust in Linux was a huge mistake that we should rip out right now before it is too late.

Re: [TECH TOPIC] Implementing malloc

[Greg KH]

On Thu, Jul 09, 2026 at 10:30:53AM -0700, H. Peter Anvin wrote:
> On July 9, 2026 10:11:21 AM PDT, Matthew Wilcox <willy@infradead.org> wrote:
> >On Thu, Jul 09, 2026 at 09:58:37AM -0700, Kees Cook 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.
> >> 
> >> No surprise, but I strongly disagree with this. Those APIs are flawed
> >> and we shouldn't emulate them. This is why we just removed strncpy(),
> >> for example.
> >> 
> >> Allocations need to be type-based, not size-based. When we force people
> >> to reduce it to just byte count tons of metadata that can be used by
> >> both the kernel and the compiler is lost. The size is a by-product of
> >> "what do you need space for?" "I need X many Foo objects" or "I need
> >> Bar with Z many trailing Baz objects" or even "I need a plane of pixels
> >> X by Y". The uncommon case is "I need X many bytes from this stream".
> >
> >I agree that many memory allocations benefit from providing more semantic
> >information to both the compiler and the runtime, as you suggest.
> >What I don't think we benefit from is "And you have to pass this magic
> >GFP_KERNEL argument too.  Unless it's GFP_ATOMIC or something".
> >
> >Maybe I'm confusing / distracting by framing this around "Hey, malloc()
> >is a great interface and we should implement it" when what I really mean
> >is "GFP flags suck and we should strive to redesign the kernel so that
> >the vast majority of allocations don't need them".
> >
> >I'm happy to rephrase the proposal in that way if it'll help.  I thought
> >that malloc() would be the right vehicle for getting my point across,
> >but it seems to be a distraction.
> >
> >What I really don't want to see is a whole pile of Rust changes to
> >accommodate having to pass GFP flags to memory allocations.  Would that
> >be a better vehicle for the discussion?
> >
> 
> If Rust can't deal with different memory allocators then Rust in Linux was a huge mistake that we should rip out right now before it is too late.
> 

Um, rust already handles the GFP flags just fine for the allocators.
What is missing from what is there today?

thanks,

greg k-h

Re: [TECH TOPIC] Implementing malloc

[Miguel Ojeda]

On Thu, Jul 9, 2026 at 7:13 PM Matthew Wilcox <willy@infradead.org> wrote:
>
> What I really don't want to see is a whole pile of Rust changes to
> accommodate having to pass GFP flags to memory allocations.  Would that
> be a better vehicle for the discussion?

Currently we already pass the GFP flags and support different allocators.

For context, initially we used a vendored `alloc` crate, because we
were trying to see if upstream could give us what we needed.

Then in 2024 (v6.10) we were able to drop the vendored copy by using a
workaround by Wedson that allowed us to pass the GFP flags and avoided
our reliance on upstream's allocator unstable feature:

  b6a006e21b82 ("rust: alloc: introduce allocation flags")

Later that year (v6.13), we couldn't wait much more, so we ended up
implementing our own `alloc` module and allocator support on our side
by Danilo:

  b7a084ba4fbb ("rust: alloc: add `Allocator` trait")

Cc'ing rust-for-linux and Danilo.

Cheers,
Miguel

Re: [TECH TOPIC] Implementing malloc

[Miguel Ojeda]

On Thu, Jul 9, 2026 at 7:36 PM H. Peter Anvin <hpa@zytor.com> wrote:
>
> If Rust can't deal with different memory allocators then Rust in Linux was a huge mistake that we should rip out right now before it is too late.

That is not the case -- we already support it, so there is no need to
propose to remove a key feature of the future of the Linux kernel. :)

Cheers,
Miguel

Re: [TECH TOPIC] Implementing malloc

[H. Peter Anvin]

On July 9, 2026 10:40:55 AM PDT, Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
>On Thu, Jul 9, 2026 at 7:13 PM Matthew Wilcox <willy@infradead.org> wrote:
>>
>> What I really don't want to see is a whole pile of Rust changes to
>> accommodate having to pass GFP flags to memory allocations.  Would that
>> be a better vehicle for the discussion?
>
>Currently we already pass the GFP flags and support different allocators.
>
>For context, initially we used a vendored `alloc` crate, because we
>were trying to see if upstream could give us what we needed.
>
>Then in 2024 (v6.10) we were able to drop the vendored copy by using a
>workaround by Wedson that allowed us to pass the GFP flags and avoided
>our reliance on upstream's allocator unstable feature:
>
>  b6a006e21b82 ("rust: alloc: introduce allocation flags")
>
>Later that year (v6.13), we couldn't wait much more, so we ended up
>implementing our own `alloc` module and allocator support on our side
>by Danilo:
>
>  b7a084ba4fbb ("rust: alloc: add `Allocator` trait")
>
>Cc'ing rust-for-linux and Danilo.
>
>Cheers,
>Miguel
>
>

In case it was not obvious, my comment was meant to be ironic (reductio ad absurdum).

In fact, I'm surprised and worried to hear how recent this was. This underscores my main concern with Rust, which is that it seems to have *very* different stability criteria than the C code, where we are not allowed to require anything that hasn't been in gcc for 5-10 years, after which the clang people discover they never implemented it and so they ask for another 5+ years of keeping the old-syle or fallback code.

Re: [TECH TOPIC] Implementing malloc

[Dan Carpenter]

On Thu, Jul 09, 2026 at 06:11:21PM +0100, Matthew Wilcox wrote:
> I agree that many memory allocations benefit from providing more semantic
> information to both the compiler and the runtime, as you suggest.
> What I don't think we benefit from is "And you have to pass this magic
> GFP_KERNEL argument too.  Unless it's GFP_ATOMIC or something".

You know that most people are using kzmalloc_obj() these days and so
they don't pass GFP_KERNEL...

regards,
dan carpenter

Re: [TECH TOPIC] Implementing malloc

[Miguel Ojeda]

On Thu, Jul 9, 2026 at 8:18 PM H. Peter Anvin <hpa@zytor.com> wrote:
>
> In case it was not obvious, my comment was meant to be ironic (reductio ad absurdum).

Ok, I appreciate the clarification and that you consider it the right call then.

> In fact, I'm surprised and worried to hear how recent this was. This underscores my main concern with Rust, which is that it seems to have *very* different stability criteria than the C code, where we are not allowed to require anything that hasn't been in gcc for 5-10 years, after which the clang people discover they never implemented it and so they ask for another 5+ years of keeping the old-syle or fallback code.

Hmm... What is the concern? If it is about the window of supported
compilers, the current policy is to follow Debian Stable's version as
the minimum.

  https://rust-for-linux.com/rust-version-policy#minimum-upgrade-policy

It was openly discussed and finally decided in the Maintainers Summit.

As things mature and we get the improvements we want, we may want to
extend it to two Debian Stables etc.

But please note that, regarding allocators, we could have moved
earlier. As I mentioned, we waited as long as we could to see if
upstream could give us what we needed. It didn't happen, so we
pivoted, but we could have done it earlier.

Cheers,
Miguel

Re: [TECH TOPIC] Implementing malloc

[Matthew Wilcox]

On Thu, Jul 09, 2026 at 09:42:55PM +0300, Dan Carpenter wrote:
> On Thu, Jul 09, 2026 at 06:11:21PM +0100, Matthew Wilcox wrote:
> > I agree that many memory allocations benefit from providing more semantic
> > information to both the compiler and the runtime, as you suggest.
> > What I don't think we benefit from is "And you have to pass this magic
> > GFP_KERNEL argument too.  Unless it's GFP_ATOMIC or something".
> 
> You know that most people are using kzmalloc_obj() these days and so
> they don't pass GFP_KERNEL...

They are, they just don't know that they are.  Honestly, I think that's
almost worse.  Imagine if you could call kzmalloc_obj() from any context.
I think the instinct was right, but the implementation needs to be
done right.

Re: [TECH TOPIC] Implementing malloc

[H. Peter Anvin]

On July 9, 2026 11:44:11 AM PDT, Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
>On Thu, Jul 9, 2026 at 8:18 PM H. Peter Anvin <hpa@zytor.com> wrote:
>>
>> In case it was not obvious, my comment was meant to be ironic (reductio ad absurdum).
>
>Ok, I appreciate the clarification and that you consider it the right call then.
>
>> In fact, I'm surprised and worried to hear how recent this was. This underscores my main concern with Rust, which is that it seems to have *very* different stability criteria than the C code, where we are not allowed to require anything that hasn't been in gcc for 5-10 years, after which the clang people discover they never implemented it and so they ask for another 5+ years of keeping the old-syle or fallback code.
>
>Hmm... What is the concern? If it is about the window of supported
>compilers, the current policy is to follow Debian Stable's version as
>the minimum.
>
>  https://rust-for-linux.com/rust-version-policy#minimum-upgrade-policy
>
>It was openly discussed and finally decided in the Maintainers Summit.
>
>As things mature and we get the improvements we want, we may want to
>extend it to two Debian Stables etc.
>
>But please note that, regarding allocators, we could have moved
>earlier. As I mentioned, we waited as long as we could to see if
>upstream could give us what we needed. It didn't happen, so we
>pivoted, but we could have done it earlier.
>
>Cheers,
>Miguel
>

All of the above. It has been a concern of mine for a very long time. 

It's a really big asymmetry versus the C side, and at some point someone is going to want to implement a core subsystem in Rust.

"Two Debian stable" is a blink of an eye in comparison with the stability criteria that people are demanding for gcc/binutils.

Re: [TECH TOPIC] Implementing malloc

[Miguel Ojeda]

On Thu, Jul 9, 2026 at 8:50 PM H. Peter Anvin <hpa@zytor.com> wrote:
>
> All of the above. It has been a concern of mine for a very long time.
>
> It's a really big asymmetry versus the C side, and at some point someone is going to want to implement a core subsystem in Rust.
>
> "Two Debian stable" is a blink of an eye in comparison with the stability criteria that people are demanding for gcc/binutils.

I still don't understand what is the concern you are referring to.

If you have a concern, then it is because you think of a negative
situation in the future, no? So what is that situation? i.e. what is
the issue?

And, yes, quite a few people have asked about implementing a core
subsystem in Rust over the years. If it cannot be an optional
subsystem, then one will need to wait, or convince everyone else to
change the kernel policies, or convince major distributions to
backport the toolchain, or similar.

It is what it is -- after all, the point of the exercise was to take
advantage of the features from a new technology. But I don't see what
the concern is.

In any case, that discussion seems orthogonal to the allocators one.

Cheers,
Miguel

Re: [TECH TOPIC] Implementing malloc

[Linus Torvalds]

On Thu, 9 Jul 2026 at 11:59, Matthew Wilcox <willy@infradead.org> wrote:
>
> They are, they just don't know that they are.  Honestly, I think that's
> almost worse.  Imagine if you could call kzmalloc_obj() from any context.
> I think the instinct was right, but the implementation needs to be
> done right.

No, what you consider "right" really really isn't.

If you do allocations from interrupt context or from within a
spinlock, you DAMN WELL BETTER KNOW THAT.

Adding some magical "malloc()" that hides that from you, and knows
that "oh, I'm inside a spinlock, so I have to use GFP_ATOMIC" is
WRONG.

Yes, it might be "easier to use". But that's the wrong kind of easy.

If you do kernel development, you need to know that being inside a
lock is a thing, and it has consequences. You can't do vmalloc() from
inside a spinlock, and even with plain old kmalloc() you have to use
GFP_ATOMIC.

There are absolutely zero upsides to try to make allocations act as if
the kernel was user land. The kernel is not user land, and memory
allocations inside the kernel are special and we should never even
pretend anything else.

The "use kzmalloc_obj()" is just a safer and simpler interface, and
you don't have to write out that GFP_KERNEL that just happens to be
the most common case.

But it's a type-safe _convenience_, it's not a "you don't need to know
about kernel memory allocation rules".

              Linus

Re: [TECH TOPIC] Implementing malloc

[Geert Uytterhoeven]

Hi Dan,

On Thu, 9 Jul 2026 at 20:52, Dan Carpenter <error27@gmail.com> wrote:
> On Thu, Jul 09, 2026 at 06:11:21PM +0100, Matthew Wilcox wrote:
> > I agree that many memory allocations benefit from providing more semantic
> > information to both the compiler and the runtime, as you suggest.
> > What I don't think we benefit from is "And you have to pass this magic
> > GFP_KERNEL argument too.  Unless it's GFP_ATOMIC or something".
>
> You know that most people are using kzmalloc_obj() these days and so
> they don't pass GFP_KERNEL...

You know that most people are using the devm_*() allocators  these
days and so they do pass GFP_KERNEL? ;-)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [TECH TOPIC] Implementing malloc

[Laurent Pinchart]

On Fri, Jul 10, 2026 at 01:21:23PM +0200, Geert Uytterhoeven wrote:
> On Thu, 9 Jul 2026 at 20:52, Dan Carpenter wrote:
> > On Thu, Jul 09, 2026 at 06:11:21PM +0100, Matthew Wilcox wrote:
> > > I agree that many memory allocations benefit from providing more semantic
> > > information to both the compiler and the runtime, as you suggest.
> > > What I don't think we benefit from is "And you have to pass this magic
> > > GFP_KERNEL argument too.  Unless it's GFP_ATOMIC or something".
> >
> > You know that most people are using kzmalloc_obj() these days and so
> > they don't pass GFP_KERNEL...
> 
> You know that most people are using the devm_*() allocators  these
> days and so they do pass GFP_KERNEL? ;-)

I know that lots of people overuse the devm_*() allocators in ways that
are very harmfull :-)

Jokes aside, I think Kees mentioned he would extend the object
allocation API to devm_*().

-- 
Regards,

Laurent Pinchart

Re: [TECH TOPIC] Implementing malloc

[Joe Perches]

On 2026-07-10 13:21, Geert Uytterhoeven wrote:
> Hi Dan,
[]
> You know that most people are using the devm_*() allocators  these
> days and so they do pass GFP_KERNEL? ;-)

One day they won't:

https://lore.kernel.org/lkml/eed0c57a2c897e34d411229c3de41c5402791894.1781575297.git.joe@perches.com/