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: <fc255e7fb2b3fb4a2896f4e8680cca1f0cf7fe8d.camel@HansenPartnership.com>
Date: Tue, 18 Nov 2025 16:10:00 -0500
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Bart Van Assche
 <bvanassche@....org>, 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, 2025-11-18 at 15:51 -0500, Steven Rostedt wrote:
> On Tue, 18 Nov 2025 15:21:10 -0500
> James Bottomley <James.Bottomley@...senPartnership.com> wrote:
> 
> > There is one last case that hasn't been discussed, which is where
> > you deliberately introduce an extra scope block for the free and
> > allocation, so in your example above it would look like
> > 
> > 	if (ret < )
> > 		return -ERROR
> > 
> > 	[ several more error exits ]
> > 
> > 	{
> > 		struct foo *var __free(kfree) = kmalloc(...)
> > 
> > 		[...]
> > 	}
> 
> I'm not too big on explicit blocks for just declarations. Especially,
> in my case where the var is used until the end:

Well I don't do it often, but there are times when the scope of a
variable is definitely a lot less than the scope of the code block.

I see this as being analagous to when you should use a guard vs a
scoped guard.

> 
> 	{
> 		struct foo *var __free(kfree) = kmalloc(...)
> 
> 		[...]
> 
> 		return func(..., var);
> 	}
> 
> It seems a bit strange to have the final return of a function from
> within an explicit scope block.

Well, you did that ... the return could equally well have been outside
the block.  However, I do think additional scoped blocks for variables
looks most readable when the scope of the variable is less than the
code on both sides.  If the variable doesn't go out of scope until the
final return, I can see an argument for just doing an interior
declaration.

Regards,

James

>  Especially since the beginning is just for error conditions, and the
> meat of the function is now in that explicit block.
> 
> -- Steve
>