Re: [RFC PATCH glibc] Linux: Use fixed rseq_len value for rseq registration

[Szabolcs Nagy <szabolcs.nagy@arm.com>]

The 07/14/2020 11:30, Mathieu Desnoyers via Libc-alpha wrote:
> > I think we are looking at this from the wrong perspective.  It's not
> > userspace that is setting the size here, it's the kernel based on the
> > features it supports.  So the kernel should put the size into the
> > auxiliary vector, and the registration should use that size.  But that
> > doesn't align well with the use of an ELF TLS symbol.

this is why it is better to use a function that returns
a pointer than a tls symbol as public abi.

> We have a few possible ways to do things here:
> 
> 1) Kernel exports supported size, incompatible with ELF TLS symbol,
> 
> 2) Userspace dictates supported size, compatible with ELF TLS symbol,
>    triggers failure if the kernel supports a smaller size,
> 
> 3) Userspace lets kernel know how much space is available for struct rseq
>    (through user_size field), and the kernel lets user-space know how much
>    of that structure is being filled (through kernel_size field). This
>    would also be compatible with ELF TLS symbol AFAIU, and would allow
>    extending struct rseq.
> 
> Option (3) would allow us to have the speed gains that come with using a
> TLS from the fast-path, while allowing extension of struct rseq.
> 
> Or is there anything in that scheme that breaks ELF rules or C language
> requirements ?

how would users access those extension fields?

how would the public struct definition change?