[PATCH] Reserve static TLS for dynamically loaded initial-exec TLS only [BZ #25051]
Carlos O'Donell
codonell@redhat.com
Thu Feb 20 15:05:00 GMT 2020
On 2/17/20 11:01 AM, Florian Weimer wrote:
> * Carlos O'Donell:
>
>> Let me take a stab at this:
>>
>> (1) File a bug to indicate all libraries must stop using
>> TLS IE to fix dlmopen issues with TLS IE.
>
> Do you mean glibc components, or do you view this as a distribution-wide
> change?
All glibc libraries should stop using TLS IE and we should file bugs for
fixing these instances where TLS IE was used to work around startup ordering
problems.
I did not intend to imply a distribution-wide policy. Other packages can do
what they want, and their use of TLS IE will limit dlmopen capabilities
including causing it to fail.
>> (2) Set DL_NNS to 4, and add a tunable that lets you change
>> the limit to reduce surplus memory allocated.
>>
>> (2.a) send linux man-pages a patch to make dlmopen(3)
>> ambiguous about how many namespaces are supported and
>> to point at the tunable to increase the memory used.
>>
>> (3) I think that the surplus should be split into two
>> blocks:
>> (3.a) Some reserved for TLS IE libs.
>> (3.b) Some reserved for tlsdesc optimization.
>>
>> My opinion is that any library that is loaded and
>> needs TLS IE should be able to use (3.a). We should
>> reserve enough for (3.a) to be able to load glibc
>> libraries, libgomp, and libgl (as you note).
>
> There's also a potential for not letting audit libraries consume
> namespace slots (once they are dynamic). This will enable lower DL_NNS
> defaults.
I don't quite follow what you mean here, can you expand on that?
--
Cheers,
Carlos.
More information about the Libc-alpha
mailing list