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: Rich Felker <dalias at aerifal dot cx>
- 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>
- Date: Thu, 19 Sep 2013 00:38:12 -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 Wed, Sep 18, 2013 at 04:26:23PM -0700, 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.
For what it's worth, we have fully async-signal-safe and fail-safe (no
possibility to abort due to allocation failure) dynamic TLS in musl
libc.
> 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.
> ....
> > 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 sufficient? Unless you take precautions, I think you could run
into the situation where a signal handler is invoked while the thread
is setting up its dynamic TLS, thereby possibly discarding changes
made to TLS from the signal handler and possibly leaking memory.
Fixing these issues is possible but difficult; the cleanest approach I
know uses atomic operations -- something of the form:
1. Allocate space for TLS.
2. Copy TLS image.
3. Install the TLS with atomic CAS, expecting the old pointer to be
NULL. If it's not NULL, free the just-allocated space.
Note that in step 3 the CAS need not be a memory barrier, but it needs
to be atomic in the sense that a signal handler cannot step in between
the compare and the write.
Rich