Re: [TECH TOPIC] Implementing malloc

On Thu, 9 Jul 2026 at 11:59, Matthew Wilcox <[email protected]> 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