[REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere

[Thomas Gleixner]

On Mon, Apr 27 2026 at 14:35, Mathieu Desnoyers wrote:
> On 2026-04-27 03:40, Florian Weimer wrote:
>> Switching to the new extensible RSEQ allocation code in older glibc
>> builds is not entirely trivial, and I would prefer not doing that.
>> Registering with a new flag is comparatively simple, and we could
>> backport it, except that it might not be compatible with CRIU.
> A third option would allow the entire range of older libc versions to
> benefit from rseq optimizations, gating the "v2" behavior on:
>
>    rseq_len > 32 || (flags & RSEQ_FLAG_V2)

No. Features beyond mm_cid require optimized mode and a larger rseq
area. That's not negotiable. See below.

> That v2 behavior would:
>
> A) Enforce the ABI contract:
>
>     - RO fields corruption -> kill process,

My patch does that already and the time slice extension muck does so too
from day one.

>     - System call within rseq critical section -> kill process,

No. That's overkill for syscall heavy workloads.

Also it's not a functional correctness problem which affects multiple
RSEQ users in an application. User space can do even worse things.

      cs_start
      call foo	// foo uses rseq too ....
      cs_end

Invoking a syscall from within the critical section is stupid, but at
least harmless vs. other usage in the same thread as the syscall needs
to return before anything else can go and use RSEQ in that thread, no?

People who develop RSEQ critical sections can enable debug mode via the
sysfs knob if they want to prove that their code is correct. That's a
debug aid, not more.

> B) Allow optimization of the rseq field updates (only update relevant
>     fields on migration),

That's part of the whole combo. Optimized behaviour and new features.

> This entirely decouples the feature enablement concern (rseq_len) from
> the strictness/optimization mode (v2).

Which causes us to sprinkle more conditionals into the hot paths for
individual features instead of simply doing unconditional stores and be
done with it. It's bad enough that we have one, we don't need more.

User space knows the size the kernel expects and if it insists on using
the original size, so be it. Keep it simple.

Thanks,

        tglx