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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=whQ9kzJWFrCY9C3bPkdfW5Zb0TdvKNdPCdzPSnrzHyhVw@mail.gmail.com>
Date: Tue, 18 Nov 2025 12:23:01 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Bart Van Assche <bvanassche@....org>, 
	James Bottomley <James.Bottomley@...senpartnership.com>, ksummit@...ts.linux.dev, 
	Dan Williams <dan.j.williams@...el.com>, linux-kernel <linux-kernel@...r.kernel.org>, 
	Dan Carpenter <dan.carpenter@...aro.org>
Subject: Re: Clarifying confusion of our variable placement rules caused by cleanup.h

On Tue, 18 Nov 2025 at 11:55, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> Doesn't look nice. I wonder since its the first allocation, if doing:
>
>         struct ring_buffer_cpu_meta *meta;
>         struct buffer_page *bpage;
>         struct page *page;
>         int ret;
>
>         struct ring_buffer_per_cpu *cpu_buffer __free(kfree) =
>                  kzalloc_node(ALIGN(sizeof(*cpu_buffer), cache_line_size()),
>                                     GFP_KERNEL, cpu_to_node(cpu));
>         if (!cpu_buffer)
>                 return NULL;
>
> Would be acceptable?

So no, I do not think this is something we want to do, because that
thing is just stupidly complicated and as such I think it *wants* to
be broken up into multiple pieces.

But this is also literally *why* I was talking up that automatic type
thing, because I think that together with a few helper macros, we
*can* make cases that would otherwise look like the above horror-show
actually work really nicely.

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.

Because in the simpler - and I suspect *much* more common - cases, you
could easily end up with something simpler like

       auto cpu_buffer __free(kfree) = kmalloc_type(struct ring_buffer_per_cpu);

and at *that* point I think it's nice. But please - not your horror-show.

Because if you need three lines to make one allocation be legible,
just separate it out.

                 Linus