[PATCH] Linux: Remove rseq support

[Szabolcs Nagy]

The 07/17/2020 10:26, Florian Weimer wrote:
> * 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.

64 + 16*100 == 1664

it allowed as many namespaces as would fit in that.

but more importantly users could dlopen modules
with 1664 byte ie tls.

i consider dlmopen less important for abi compat
as it's less widely used than dlopen, if libc
tls usage increase then some existing applications
may stop working that abused static tls, but if
libc tls use stays the same then nothing changes.

> 
> 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.

rseq increased the contract temporarily to make
some tests working, but i don't think that's
relevant (my patches didn't change because of
rseq).

the new contract officially supports:
- 4 namespaces
- 144 bytes ie tls dlopened per namespace

unofficially we support old applications that
used 1 namespace and dlopened 1664 byte ie tls,
this is why at dlopen time we don't actually
check if more ie tls is loaded into the namespace
than 144.

i think we should not reduce LIBC_IE_TLS if
libc uses less tls, the contract still works,
if libc starts using more than 192 byte TLS,
then it should be increased. (the test may
need to change then, but i think they really
for testing existing application behaviour
that should be supported, so probably only
the comments need to change)

> 
> 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.

no, that test passed with glibc 2.31 and
i think it should pass with 2.32 too.