Re: [RFC PATCH 1/5] rseq: uapi: add rseq operation definitions

[Olivier Dion <odion@efficios.com>]

On Mon, 31 Aug 2026, Florian Weimer <fweimer@redhat.com> wrote:
[...]
>> Indeed, TCMalloc relies on the behavior of RSEQ v1, that reset the
>> cpu_id bits in the RSEQ shared region, to invalidate a per-cpu pointer
>> cached in a TLS. This hack requires TCMalloc users to use a glibc
>> tunable to disable RSEQ registration for threads so that TCMalloc can
>> register its own region, overlapping the TLS cache.
>
> The commit message does not quite say how this addresses tcmalloc needs.
> I assume the idea is to reset some other data structure and not the rseq
> fields.  Is my assumption correct?

Indeed.  That would allow TCMalloc to not have to overlap their pointer
cache with their RSEQ area.  In other words, they could be using the
glibc area and be compatible with the rest of the ecosystem.

> Would it be possible to use actual CPU instructions running in userspace
> for this?  I assume not because it's not possible to restore the
> register contents.

Well I had in mind another solution, albeit some might find it ugly but
I think it does have the merit to be explored.

Basically, instead of doing all the operations in the kernel, we could
setup something akin to a signal handler by pushing a frame on the
userspace stack and resuming the execution of the thread into that
"handler".  Userspace is now responsible of everything, including
returning to the original IP.

However, we need to be careful with things like the red-zone, the
shadow-track and the extended states.  Other than that, the only thing I
am unsure is how to handle nesting.  Perhaps someone with more
knowledges could expand on that.

> My concern is that this would turn into another bytecode interpreter
> over time, basically reimplementing BPF.

I did think about adding BPF type to run BPF bytecode.  However, I don't
think it fits well the goal here and would make the feature unusable on
configurations where BPF is not available.

Overall, my idea with the RSEQ operations was make that could benifit
the userspace as a whole instead of handling only the TCMalloc
situation.  Otherwise, I would have just name it RSEQ reset.

For example, there is a CPU-stride variant of the reset operation.  I
dabble with this operation to cache a TLS that is global-dynamic into a
per-cpu cache.  Thus, making a TLS global-dynamic access as fast as a
TLS initial-exec.

Thanks,
Olivier
-- 
Olivier Dion
EfficiOS Inc.
https://www.efficios.com