[PATCH] Avoid using up static TLS surplus for optimizations [BZ #25051]

[Carlos O'Donell]

On 6/4/20 9:54 AM, Florian Weimer via Libc-alpha wrote:
> * Szabolcs Nagy:
> 
>> +void
>> +_dl_static_tls_tunables_init (void)
>> +{
>> +  size_t nns, opt_tls;
>> +
>> +#if HAVE_TUNABLES
>> +  nns = TUNABLE_GET (nns, size_t, NULL);
>> +  opt_tls = TUNABLE_GET (optional_static_tls, size_t, NULL);
>> +#else
>> +  /* Default values of the tunables.  */
>> +  nns = 4;
>> +  opt_tls = 512;
>> +#endif
>> +  if (nns > DL_NNS)
>> +    nns = DL_NNS;
>> +  GL(dl_tls_static_optional) = opt_tls;
>> +  GLRO(dl_tls_static_surplus) = ((nns - 1) * LIBC_IE_TLS
>> +				 + nns * OTHER_IE_TLS
>> +				 + opt_tls);
>> +}
> 
> I think the default 4 is incompatible with elf/tst-manyaudit.  The test
> doesn't check that all specified audit modules have been loaded.
> 
> I think we can automatically increase the number of namespaces based on
> the count of audit modules.  This can be a follow-up patch, and I can
> work on this.

For context Florian and I were discussing this patch, along with the changes
Florian was making for late failure audit modules crashing (which itself
was related to rseq changes).

I agree with Florian that 4 is incompatible with elf/tst-manyaudit, and
my opinion is that if we can't load an audit module we should fail to start
the process. The user, via env vars, or via DT_AUDIT, has requested auditing
and auditing is an integral part of some customer workflows because it allows
modifying the loader's behaviour. To fail to load an audit module is a critical
process startup failure in my opinion. I could be convinced otherwise, but I'd
have to hear some fairly cogent arguments in that direction.

As a follow-up patch I'd like to see the number of audit modules get counted,
and then the number of namespaces increased, and then static tls adjusted
accordingly to make it work. Note that you'll have to set the nns tunable's
minimum value based on number of modules being requested, and it should
override the tunable if the tunable is too low. That is to say that a low
tunable value for nns is ignored if you specify lots of LD_AUDIT or DT_AUDIT
modules. The tunables are only a hint and if it's too low it will be ignored.
Setting the dynamic minimum is important because it allows you to run ld.so
with --print-tunables (something I've asked HJ to work fix for the x86
tunables that have a dynamic minimum also) it will show how many namespaces
is the minimum.

-- 
Cheers,
Carlos.