Re: [PATCH 1/8] mm: introduce for_each_process_rcu and for_each_thread_rcu

[Peter Zijlstra <peterz@infradead.org>]

On Sat, Sep 05, 2026 at 09:27:33AM +0200, Thomas Gleixner wrote:
> On Fri, Sep 04 2026 at 19:07, Steven Rostedt wrote:
> > On Fri, 04 Sep 2026 23:17:38 +0200
> > Thomas Gleixner <tglx@kernel.org> wrote:
> >
> >> No. Scopes can be left by any valid termination mechanism. 
> >> 
> >> The only problematic case of leaving a scoped_guard() with goto is when
> >> the goto is actually implemented as an ASM goto. See the comment above
> >> arch_unsafe_get_user() in linux/uaccess.h.
> >
> > Oh OK. I was under the impression that goto's could cause undefined
> > behavior with guards. Or is that just when a goto jumps over one? Or is
> > that OK too?
> 
> Jump where ever you want. The keyword is 'scope'.
> 
> The normal visibility rules of variables in C scopes apply. So if the
> scope for which a variable is defined is left and the variable is
> defined with __attribute__((__cleanup__(cleanup_func))) then the compiler
> inserts a call to 'cleanup_func()'.
> 
> The problem with ASM GOTO is that the 'goto' is not visible to the C
> compiler because it is burried in the asm inline. Clang detects it at
> some later point and fails the build. GCC simply emits buggy code or at
> least used to. Haven't checked whether that's still the case.
> 
> So we worked around that by letting the ASM goto jump to a local label
> within the scope and use goto 'outofscope' from there. That makes it
> observe that the scope is left and the cleanup call is inserted at the
> right place. See 3eb6660f26d1 ("uaccess: Provide ASM GOTO safe wrappers
> for unsafe_*_user()")

Right, so GCC will accept and miscompile jumps into a scope. Clang will
warn/error about this, so this should never happen.

Aside from the ASM GOTO issue, there is also an issue with computed
goto, those don't work either.