linux-kernel - Re: [RFC PATCH 4/5] tracing: Remove conditional locking from __DO

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: <CAHk-=wjcCQ4-0f68bWMLuFnj9r9Hwg4YnXDBg8-K7z6ygq=iEQ@mail.gmail.com>
Date: Mon, 25 Nov 2024 09:51:43 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Przemek Kitszel <przemyslaw.kitszel@...el.com>
Cc: Peter Zijlstra <peterz@...radead.org>, 
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, 
	Dmitry Torokhov <dmitry.torokhov@...il.com>, Steven Rostedt <rostedt@...dmis.org>, 
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>, 
	Michael Jeanson <mjeanson@...icios.com>, Masami Hiramatsu <mhiramat@...nel.org>, 
	Alexei Starovoitov <ast@...nel.org>, Yonghong Song <yhs@...com>, "Paul E . McKenney" <paulmck@...nel.org>, 
	Ingo Molnar <mingo@...hat.com>, Arnaldo Carvalho de Melo <acme@...nel.org>, Mark Rutland <mark.rutland@....com>, 
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Namhyung Kim <namhyung@...nel.org>, 
	Andrii Nakryiko <andrii.nakryiko@...il.com>, bpf@...r.kernel.org, 
	Joel Fernandes <joel@...lfernandes.org>, Jordan Rife <jrife@...gle.com>, 
	linux-trace-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 4/5] tracing: Remove conditional locking from __DO_TRACE()

On Mon, 25 Nov 2024 at 07:35, Przemek Kitszel
<przemyslaw.kitszel@...el.com> wrote:
>
> At one point I had a version that did:
>         if (0)
> label: ;
>         else
>                 for (....)

Well, that is impressively ugly.

> but it is goto-jumping back in the code

I'm not sure why you think *that* is a problem. It does look like it
avoids the dangling else issue, which seems to be the more immediate
problem.

(Of course, "immediate" is all very relative - the use-case that
triggered this is going away anyway and being replaced by a regular
'guard()').

That said, I have a "lovely" suggestion. Instead of the "if(0)+goto"
games, I think you can just do this:

  #define scoped_guard(_name, args...)                                   \
         for (CLASS(_name, scope)(args), *_once = (void *)1; _once &&    \
              (__guard_ptr(_name)(&scope) || !__is_cond_ptr(_name));     \
              _once = NULL)

which avoids the whole UNIQUE_NAME on the label too.

Yeah, yeah, if somebody has nested uses of scoped_guard(), they will
have shadowing of the "_once" variable and extrawarn enables -Wshadow.

But dammit, that isn't actually an error, and I think -Wshadow is bad
for these situations. Nested temporary variables in macros shouldn't
warn. Oh well.

Is there a way to shut up -Wshadow on a per-variable basis? My
google-fu is too weak.

Did I test the above macro? Don't be silly. All my code works on first
try. Except when it doesn't.

          Linus