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:57:08 -0400
- Subject: Re: Async-signal-safe access to __thread variables from dlopen()ed libraries?
- Authentication-results: sourceware.org; auth=none
- References: <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> <20130919043812 dot GS20515 at brightrain dot aerifal dot cx> <523A8284 dot 6080506 at google dot com>
On Wed, Sep 18, 2013 at 09:50:12PM -0700, Paul Pluzhnikov wrote:
> On 9/18/13 9:38 PM, Rich Felker wrote:
>
> >>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.
>
> How does that work?
TLS is pre-allocated for the current number of existing threads at
dlopen time; if that fails, dlopen reports the failure. For new
threads, it's allocated by pthread_create (actually not treated as
dynamic TLS at all, just new static TLS), and pthread_create is
responsible for reporting the failure.
For new dynamic TLS, the first call to __tls_get_addr uses an atomic
fetch/add operation to claim part of the pre-allocated space
associated with the loaded library; there's guaranteed to be enough
because of how much was allocated.
> >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:
>
> AFAIU, Andrew's patch blocks all signals while dynamic allocation is
> taking place, to prevent self-reentry via a signal handler, and
> atomic operations to prevent a race with another thread.
Oh yes, that's the better way to do it (and actually the way we do it
in musl too -- been as while since I looked at the code).
Rich