This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Async-signal-safe access to __thread variables from dlopen()ed libraries?
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Paul Pluzhnikov <ppluzhnikov at google dot com>, Ian Lance Taylor <iant at google dot com>, Roland McGrath <roland at hack dot frob dot com>, Richard Henderson <rth at twiddle dot net>, libc-alpha at sourceware dot org, Andrew Hunter <ahh at google dot com>, Alexandre Oliva <aoliva at redhat dot com>
- Date: Fri, 20 Sep 2013 09:31:22 +0200
- Subject: Re: Async-signal-safe access to __thread variables from dlopen()ed libraries?
- Authentication-results: sourceware.org; auth=none
- References: <20120612193224 dot 8E43619060E at elbrus2 dot mtv dot corp dot google dot com> <4FD8D974 dot 7090903 at twiddle dot net> <20120613182826 dot 0CFAB2C0A3 at topped-with-meat dot com> <CALoOobMtXCw+oe7ZL0=my8YH5st8b1==CasS8i07z6G9DfaX-w at mail dot gmail dot com> <20120613210444 dot 659732C095 at topped-with-meat dot com> <mcr4nqebzok dot fsf at dhcp-172-18-216-180 dot mtv dot corp dot google dot com> <20120614002931 dot ABB762C08B at topped-with-meat dot com> <mcr1uliaeep dot fsf at dhcp-172-18-216-180 dot mtv dot corp dot google dot com> <CALoOobPJ7G7ciRfc2JwzHjsDTg4-_h-SXqeU1zR4WEzoyQhyNg at mail dot gmail dot com> <523BD470 dot 6090203 at redhat dot com>
On Fri, Sep 20, 2013 at 12:52:00AM -0400, Carlos O'Donell wrote:
> > On Wed, Jun 13, 2012 at 6:08 PM, Ian Lance Taylor <iant@google.com> wrote:
> > ...
> >> Perhaps another approach would be to change __tls_get_addr to not use
> >> malloc, but to use mmap as needed. This of course assumes that mmap is
> >> in fact async signal safe although it is not on the approved list.
> >
> > Andrew Hunter has proposed a Google-local glibc patch, that
> >
> > - introduces async-signal-safe mmap-based allocator into elf/dl-misc.c, and
> > - updates the rest of the loader to use this allocator when getting space
> > for non-static TLS.
> >
> > The allocator is currently quite simple, but wastes space. It could be
> > made more space-efficient independently of other changes.
> >
How large are these allocations?
> > Is this something that has a chance of being acceptable into trunk?
>
> This is an interesting approach. Avoiding malloc certainly solves the
> problem, and it's not like the allocation patterns are sufficiently
> complex as to require malloc. We use mmap in lots of places in the
> library where the allocations are simple enough to warrant such an
> optimization.
>
> The biggest problem right now is gathering consensus on the correct
> solution.
>
Possibly we could use a generic mmap used allocator for internal usage.
This would avoid problems of not being safe when custom allocator is
used.
This would also simplify a malloc implementation a bit as we would not
worry about malloc usage in loader.