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

[Florian Weimer <fweimer@redhat.com>]

* Olivier Dion:

>> 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.

On mere context switch (not signal delivery), I don't think the kernel
assumes that there is a valid stack pointer.  These scheme would change
that.  This would be fine for managed code, but this scheme has to work
with arbitrary code that reassigns registers temporarily.

(We had a longjmp on POWER for a while that corrupted the stack pointer
temporarily, and that was visible only upon signal delivery, not regular
context switch.)

> 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.

I don't think this can work?  The problem with global-dynamic TLS is
that it can't be a single memory block (it may have to grow).  Even
if the access path changes, we can't relocate the memory because
TLS objects must live in the linear address space.

We can do away with the current complicated scheme in glibc and use an
array of arrays, where the inner arrays follow an exponential growth
policy (for size and alignment).  That would still have dependent loads,
but would be quite a bit faster than our current global-dynamic scheme.

  New TLS allocator for glibc
  <https://conf.gnu-tools-cauldron.org/opo25/talk/LQTU3G/>

(Sadly still not implemented.)

Thanks,
Florian