Re: [RFC PATCH 4/5] tracing: Remove conditional locking from __DO_TRACE()

From: Linus Torvalds
Date: Mon Nov 25 2024 - 12:59:51 EST


On Mon, 25 Nov 2024 at 07:35, Przemek Kitszel
<przemyslaw.kitszel@xxxxxxxxx> 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