This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Async-signal-safe access to __thread variables from dlopen()ed libraries?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]