[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