Re: Clarifying confusion of our variable placement rules caused by cleanup.h

[Linus Torvalds <torvalds@linux-foundation.org>]

On Tue, 18 Nov 2025 at 12:23, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Now, I think that your crazy case that wants to do alignment etc may
> never be a good example of this, but for the simpler case of "I just
> want a normal allocation for this" a couple of helper macros would
> make it quite nice.

Actually, if we made some "kmalloc_type()" helper macro also do
__alignof__ in addition to the sizeef() , and _if_ the type itself
already has the proper alignment information, it probably would work
fine for most cases.

Your particular example is still too specialized, though, with that
whole "I want a particular node" and a "I want the dynamic cacheline
alignment" rather than "current node" and "static alignment based on
type".

So I think *that* particular case is always specialized enough that
there won't be some simple helper macro to make it more readable, and
as a result you're actually better off just splitting it out, even if
it then results in some duplication, ie just doing

        struct ring_buffer_per_cpu *cpu_buffer __free(kfree);

        cpu_buffer = kzalloc_node(...);

as separate things (but probably next to each other, so that the
"__free(kfree)" part makes sense because the allocation is right
there).

But hey, you could also just make your own alloc/free wrapper
functions, and try to make it more legible that way.

Just a simple

    struct ring_buffer_per_cpu *cpu_buffer_alloc()
    { return kzalloc_node(...); }

would then make that otherwise nasty allocation then become just

    auto cpu_buffer __free(kfree) = cpu_buffer_alloc();

and suddenly it all looks pretty simple. No?

But please do _not_ spread one complex thing over three lines. Split
it up *somehow* to make it easier to read.

Either by just splitting it up into multiple parts, or maybe like the
above with a helper wrapper allocator or whatever.

Helper wrappers that are just used once or twice can still be nice
readability improvements just because they make each part be easier to
read on its own.

              Linus