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



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