This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Reserve static TLS for dynamically loaded initial-exec TLS only [BZ #25051]
- From: Florian Weimer <fweimer at redhat dot com>
- To: Carlos O'Donell <codonell at redhat dot com>
- Cc: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, nd at arm dot com, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 17 Feb 2020 17:01:54 +0100
- Subject: Re: [PATCH] Reserve static TLS for dynamically loaded initial-exec TLS only [BZ #25051]
- References: <44eaccc2-f760-88c0-989a-e413e328b051@arm.com> <87lfqjv56h.fsf@oldenburg2.str.redhat.com> <5533fb62-c336-45b3-71ec-30c5e7d7ac4c@arm.com> <ed66e69b-d20c-ebae-39f3-778a5863ad53@arm.com> <5474f68c-b093-8791-ca0b-b4b715174e2c@redhat.com>
* 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?
> (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.
Thanks,
Florian