Re: [PATCH] Async signal safe TLS accesses

[Andrew Hunter <ahh at google dot com>]

I'm looking into fixing TLDDESC.  Is this the best available documentation:

http://www.fsfla.org/~lxoliva/writeups/TLS/RFC-TLSDESC-x86.txt

?

I note with some interest that using mask_all_signals whenever we take
dl_load_lock would (very nearly, except for STB_GNU_UNIQUE symbols)
solve the problem outright.  I welcome comment from others as to
whether this carries acceptable overhead.

If not, I see two obvious possibilities

- deprecate lazy relocations; I'm unclear if the gains from not doing
a single dl_lookup_symbol_x per reloc at dlopen time are actually
significant (though maybe I'm missing the point of lazy relocations?)
AFAICT, the current scheme is more than capable of supporting the
TLSDESC indirections that actually use __tls_get_addr and friends.  I
favor this scheme unless someone can tell me a good reason not to do
so.

- mask signals in _dl_tlsdesc_resolve_rela_fixup;  use a dedicated
lock instead of dl_load_lock in _dl_tlsdesc_resolve_early_return_p
(easy). make dl_lookup_symbol_x async-signal-safe (ugh).

Open to other suggestions as well.

On Fri, Dec 6, 2013 at 1:53 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 12/05/2013 03:01 PM, Andrew Hunter wrote:
>>     TLS accesses from initial-exec variables are async-signal-safe.  Even
>>     dynamic-type accesses from shared objects loaded by ld.so at startup
>>     are.  But dynamic accesses from dlopen()ed objects are not, which
>>     means a lot of trouble for any sort of per-thread state we want to
>>     use from signal handlers since we can't rely on always having
>>     initial-exec.  Make all TLS access always signal safe.
>
> Except for any TLSDESC based accesses which are still AS-unsafe?
>
> Cheers,
> Carlos.
>