Re: [PATCH 0/4] Restartable Sequences support for glibc 2.30

[Mathieu Desnoyers <mathieu dot desnoyers at efficios dot com>]

----- On Mar 22, 2019, at 3:45 PM, Carlos O'Donell codonell@redhat.com wrote:

> On 3/22/19 1:51 PM, Florian Weimer wrote:
>> * Carlos O'Donell:
>> 
>>> On 3/22/19 1:39 PM, Florian Weimer wrote:
>>>> * Mathieu Desnoyers:
>>>>
>>>>> The only point that still appears to not reach concensus is whether it's
>>>>> acceptable to define the RSEQ_SIG code signature for each architecture.
>>>>> If I missed other points that failed to reach concensus, please let me
>>>>> know!
>>>>
>>>> I still think the registration mechanism is very problematic and
>>>> should be avoided.
>>>
>>> The *entire* registration mechanism?
>> 
>> The reference-counting part.  It's going to be of limited use, for a
>> few years at most, and we'll have to carry it forward indefinitely.
>> I don't think it's worth the complexity.
> 
> I can understand Mathieu's position here, he wants to enable all
> kinds of users, and wants to write libraries that use rseq today
> but which work with future glibc. This is a perfectly reasonable
> thing to want. The question we have to ask is the cost.
> 
> My suggestion is as follows, tell me what you think:
> 
> (a) Add a RSEQ_REGISTER_ALWAYS. The meaning of which is that the
>     core C library does unconditional registration/unregistration
>     for all threads, and that your application must not call
>     rseq with flags 0 (register)/RSEQ_FLAG_UNREGISTER.
> 
> (b) In a few years we remove all the ref count code and define
>     a __rseq_lib_abi with a register_state that is set to
>     a constant value of RSEQ_REGISTER_ALWAYS, and do nothing else.
> 
> This way we have a way to backout the ref count process and just
> leave a public data symbol as the only part of the ABI.
> 
> My idea is that we just need one more RSEQ_REGISTER_* value to
> indicate that libc has taken over unconditional registration.
> 
> Thoughts?

I think we can do even simpler.

We can move the TLS refcount and state to an external library (librseq).

glibc would expose a new global "int" variable symbol __rseq_handled acting as
a boolean. It would be initially 0. glibc would set it to 1 in its C startup
code when it effectively handles rseq registration. That symbol would _not_ be
a TLS (it's global).

librseq would be a new library used by early rseq adopters. It would expose a
rseq register/unregister API, which internally would:

- Check whether __rseq_handled is true. If so, it would do nothing, leaving
  rseq registration to the libc.
- If __rseq_handled is false, deal with many early adopters with TLS refcount
  and state variables internal to librseq.so.

That should take care of minimizing those metrics:
- glibc ABI complexity and maintenance burden in the long term,
- pain for rseq early adopters when upgrading to newer glibc,

Does that make sense ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com