[RFC PATCH glibc] Linux: Use fixed rseq_len value for rseq registration
Szabolcs Nagy
szabolcs.nagy@arm.com
Tue Jul 14 16:01:21 GMT 2020
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?
More information about the Libc-alpha
mailing list