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] [day] [month] [year] [list]

Message-ID: <ac4c502d1220f970e04dde81163bdd6c15d39f49.camel@HansenPartnership.com>
Date: Tue, 18 Nov 2025 18:32:34 -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 17:34 -0500, Steven Rostedt wrote:
> On Tue, 18 Nov 2025 16:10:00 -0500
> James Bottomley <James.Bottomley@...senPartnership.com> wrote:
> 
> > > 
> > > 	{
> > > 		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.
> 
> I guess you mean by adding a ret value?

Well yes, that was the difference.

> 	{
> 		struct foo *var __free(kfree) = kmalloc(...)
> 
> 		[...]
> 
> 		ret = func(..., var);
> 	}
> 
> 	return ret;
> 
> As the var that is passed to the function that this function is
> retuning (tail call) is only scoped inside the brackets. But anyway,
> I don't plan on changing the code in question here.
> 
> I do quite often use the scoped_guard() as that does document exactly
> what the guard is protecting.

But how would that be different from a declaration scope with the
declarations at the top?  In many ways that's precisely what for (int
i=0 ...) is except we don't have a generic way of doing it as a block
prefix statement for a bunch of variables.

Regards,

James