Re: static TLS exhausted on ppc64le

[Matt Turner <mattst88 at gmail dot com>]

On Mon, Sep 30, 2019 at 7:23 AM Rich Felker <dalias@libc.org> wrote:
>
> On Mon, Sep 30, 2019 at 02:14:46PM +0000, Szabolcs Nagy wrote:
> > On 30/09/2019 15:02, Dan Horák wrote:
> > > Hi,
> > >
> > > I would like to open a problem we have already met twice in Fedora. the
> > > symptom is
> > >
> > > "/lib64/libgomp.so.1: cannot allocate memory in static TLS block"
> > >
> > > usually when loading a lot of libraries/modules into a Python
> > > application. It happened on ppc64le and also on aarch64 systems.
> > >
> > > We have 2 reports in Fedora bugzilla about with more details.
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1722181
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1738752
> > >
> > > We have already discussed that briefly with Florian and other members of
> > > the Red Hat toolchain team, but outcome was in form of a recommendation
> > > to reduce the usage of "static TLS" objects in the individual libraries.
> > > But the open question still is - is there a fix for the TLS space
> > > exhaustion? I believe it can easily become a more serious problem soon.
> >
> > (a workaround is preloading the problematic libs at startup time)
> >
> > i think it's a bug in libgomp.so.1, gcc should not build
> > broken dsos by default (unless it can ensure they are never
> > loaded dynamically):
> >
> > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgomp/configure.tgt;h=b88bf72fe3de3735929635c874b8da375c841b1d;hb=HEAD#l13
> >
> > (libitm has a similar hack)
> >
> > e.g. this is patched out manually when building a musl libc
> > based toolchain since musl does not reserve static tls for
> > broken dsos.
> >
> > i would support removing such hacks from gcc target libs
> > (or at least hide it behind some obscure config option),
> > but i guess that should be discussed with gcc maintainers
> > and not on libc-alpha.
>
> I'm strongly in favor of such a change. I'd also like to propose that
> glibc deprecate dlopen of libraries with initial-exec access to their
> own TLS and set an EOL for it. While the GCC stuff can be fixed
> without doing that, GPU vendors are going to keep doing this until
> it's hard-breaking.

Or you submit the patches you mentioned about a year ago in [0] :)

For what it's worth, this came up again in a recent merge request [1].
Your insights (and patches!) would be appreciated.

[0] https://bugs.freedesktop.org/show_bug.cgi?id=35268#c30
[1] https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1974