Re: [PATCH] Async signal safe TLS accesses

["Carlos O'Donell" <carlos at redhat dot com>]

On 09/23/2013 10:57 PM, Rich Felker wrote:
> On Mon, Sep 23, 2013 at 04:01:29PM -0700, 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.
>>
>> Doing this has a few components to it:
>>
>>  * We introduce a set of symbols symbol_safe_{malloc,free,memalign,&c}.
>>    They do what it says on the box, but guarantee async-signal-safety.
>>    We provide a minimal mmap-based implementation in ld.so; anyone can
>>    override them more efficiently.  (This may prove useful elsewhere.)
>> [...]
>>  
>>      # Pointer protection.
>>      __pointer_chk_guard;
>> +
>> +    # for signal safe TLS
>> +    signal_safe_malloc; signal_safe_free; signal_safe_memalign;
>> +    signal_safe_realloc; signal_safe_calloc;
> 
> These symbol names are not acceptable; they are in the space of names
> reserved for the application, and since you're allowing them to be
> overridden, a conforming application can cause horrible mayhem by
> happening to use the same names for a different purpose. (In the worst
> case, imagine an application defining signal_safe_malloc in a way that
> uses TLS, such that signal_safe_malloc and __tls_get_addr become
> mutually recursive...)

I'm pretty sure that we have consensus that the public API will
need to be done as a follow-on patch to the original support for
TLS in signal handlers.

Thus I don't think we need to worry about this yet, but you can
start talking about it and discussion what it should be named.

What do you suggest?

Cheers,
Carlos.