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

[Rich Felker <dalias at aerifal dot cx>]

On Fri, Sep 20, 2013 at 12:52:00AM -0400, Carlos O'Donell wrote:
> 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?

If TLS allocation fails, there is no way the program can make forward
progress at all. glibc aborts in this case.

> > 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).

There are plenty of cases where you want TLS in signal handlers
though. My best example is a short, simple tlsigaction.c I wrote that
lets you install thread-local signal handlers -- very useful if you
want to trap synchronous signals like SIGBUS.

> 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.

Agreed. In principle, I think efforts should be made to make
operations AS-safe when there's no obvious reason (explicit
allocation, global state, etc.) for the function to be AS-unsafe.

> >> 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.

I think this would be an improvement, while still leaving glibc's
dynamic TLS behavior far from ideal.

Rich