[PATCH] Linux: Remove rseq support

[Florian Weimer]

* Szabolcs Nagy:

> The 07/17/2020 09:47, Florian Weimer wrote:
>> * Szabolcs Nagy:
>> 
>> > the test is doing its thing.
>> >
>> > its testing an internal contract about static tls usage
>> > as documented in the commit message.
>> >
>> > 192 bytes is reserved for the libc (this was decided with
>> > rseq in mind), this is larger than needed so that we don't
>> > have to change the contract often: doing that affects
>> > stack usage too and how the tls optimizations are done etc.
>> >
>> > if we change the contract the test should change too, and
>> > we should adjust the size reserved for optimizations too:
>> > the idea was to keep static tls usage the same for now,
>> > just allocate them into separate buckets of libc, ie tls
>> > and tls optimizations.
>> 
>> In the rseq revert, I changed the libc estimate to 160 bytes (from 192).
>> How should I adjust the test so that it again tests its objectives?
>
> the contract was carefully designed not to change the
> overall static tls use for now, otherwise existing
> applications that abuse static tls would start failing.
>
> i think we want existing applications to work and only
> force new applications to use the new tunables.
>
> if you change the contract you have to come up with
> a new design and a test for that design, e.g. if
> you no longer care about old applications that dlopen
> a lot of ie tls then the test should behave accordingly.

We used to have (in glibc 2.31):

  64 + DL_NNS * 100

This results in 1124 bytes.  Static TLS usage of libc.so was 144 bytes
(on x86-64).  This means that 7 namespaces could be used (without any
application TLS data) or 980 static TLS bytes from dlopen.

With the rseq ABI, we had 1664 bytes of TLS reserve, and glibc used 168
bytes of static TLS data.  This gives us 9 namespaces, or 1496 bytes of
application static TLS data.

Without the rseq ABI, we are back to 144 bytes, and the elf/dl-tls.c
formula results in 1568 bytes (with 160 bytes attributed to libc). This
us 10 namespaces or 1424 bytes of static TLS data for applications.
These values are still larger than what we had in glibc 2.31, so this
should be fine from a compatibility point of view?

I can change the magic constant to 168, to reflect that the linker
editor did a poor job with the static TLS layout, resulting in
unnecessary padding.  I'm checking if this fixes the test on
powerpc64le.  But I really think this is a test bug.

Thanks,
Florian