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: "Carlos O'Donell" <carlos at redhat dot com>
- To: Paul Pluzhnikov <ppluzhnikov at google dot com>
- Cc: 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 00:52:00 -0400
- 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>
On 09/18/2013 07:26 PM, Paul Pluzhnikov wrote:
> Resurrecting an old thread ... which began here:
> https://sourceware.org/ml/libc-alpha/2012-06/msg00335.html
>
> We really need a TLS that is both async-signal safe, and can be used from
> dlopen()ed shared library.
Do we?
I'm not against the idea, but I want us all to think critically about
the overhead we would be adding.
What happens when you call an AS-safe function from a signal handler and
it fails, thus attempting to set TLS IE errno? Does this eventually
result in a DTV_SURPLUS exhaustion i.e. fails safe?
> On Wed, Jun 13, 2012 at 6:08 PM, Ian Lance Taylor <iant@google.com> wrote:
>
>> We are currently in an unpleasant situation where it is very easy and
>> natural to use TLS variables--you just refer to them by name--and using
>> them in a signal handler almost always works just fine. Except that in
>> some highly specific but not completely implausible circumstances it
>> crashes incomprehensibly. This is not a good thing, it's a lurking time
>> bomb.
I don't buy this argument. There are *lots* of lurking bombs in C and
POSIX that can crash your application. This would be just another situation
where we need to document that TLS is not AS-safe (add it to the list of
non-AS-safe things that Alex is documenting in the manual).
However, just like all the other lurking bombs, it might be the cause
of some nasty unexplainable spectacular failure in a multi-million
line user application. If we can avoid this it would be nice.
> ...
>> 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.
>
> 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.
Cheers,
Carlos.