netdev - Re: [PATCH v1] cleanup: adjust scoped_guard() to avoid potential warning

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: <20241004093308.GI18071@noisy.programming.kicks-ass.net>
Date: Fri, 4 Oct 2024 11:33:08 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Andy Shevchenko <andriy.shevchenko@...el.com>
Cc: Przemek Kitszel <przemyslaw.kitszel@...el.com>,
	linux-kernel@...r.kernel.org, amadeuszx.slawinski@...ux.intel.com,
	Tony Nguyen <anthony.l.nguyen@...el.com>,
	nex.sw.ncis.osdt.itp.upstreaming@...el.com, netdev@...r.kernel.org,
	Markus Elfring <Markus.Elfring@....de>, Kees Cook <kees@...nel.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Dan Carpenter <dan.carpenter@...aro.org>
Subject: Re: [PATCH v1] cleanup: adjust scoped_guard() to avoid potential
 warning

On Thu, Oct 03, 2024 at 08:51:46PM +0300, Andy Shevchenko wrote:

> > I would really like to understand why you don't like this; care to
> > elaborate Andy?
> 
> To me the idea of
> 
> int my_foo(...)
> {
> 	NOT_my_foo_macro(...)
> 		return X;
> }
> 
> is counter intuitive from C programming. Without knowing the magic behind the
> scenes of NOT_my_foo_macro() I would eager to ask for adding a dead code like
> 
> int my_foo(...)
> {
> 	NOT_my_foo_macro(...)
> 		return X;
> 	return 0;
> }

Well, this is kernel coding, we don't really do (std) C anymore, and
using *anything* without knowing the magic behind it is asking for fail.

Also, something like:

int my_foo()
{
	for (;;)
		return X;
}

or

int my_foo()
{
	do {
		return X;
	} while (0);
}

is perfectly valid C that no compiler should be complaining about. Yes
its a wee bit daft, but if you want to write it, that's fine.

The point being that the compiler can determine there is no path not
hitting that return.

Apparently the current for loop is defeating the compiler, I see no
reason not to change it in such a way that the compiler is able to
determine wtf happens -- that can only help.

> What I would agree on is
> 
> int my_foo(...)
> {
> 	return NOT_my_foo_macro(..., X);
> }

That just really won't work with things as they are ofcourse.

> Or just using guard()().

That's always an option. You don't *have* to use the -- to you -- weird
form.