Re: [libc-coord] Re: RSEQ symbols: __rseq_size, __rseq_flags vs __rseq_feature_size

[Florian Weimer <fw@deneb.enyo.de>]

* Chris Kennelly:

>> If the kernel does not currently overwrite the padding, glibc can do
>> its own per-thread initialization there to support its malloc
>> implementation (because the padding is undefined today from an
>> application perspective).  That is, we would initialize these
>> invisible vCPU IDs the same way we assign arenas today.  That would
>> cover this specific malloc use case only, of course.

> If a user program updates to a new kernel before glibc does, would it be
> able to easily take advantage of it?

No, as far as I understand it, there is presently no signaling from
kernel to applications that bypasses the rseq area registration.  So
the only thing you could do is to unregister and re-register with a
compatible value.  And that is of course quite undefined and assumes
that you can do this early enough during the life-time of each thread.

But if we have the extension handshake, I'll expect us to backport it
quite widely, after some time to verify that it works with CRIU etc.