Re: [PATCH] Async signal safe TLS accesses

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

On 10/02/2013 04:52 PM, Rich Felker wrote:
> On Wed, Oct 02, 2013 at 10:57:43AM -0400, Carlos O'Donell wrote:
>> 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?
> 
> I think the public API is unrelated. For better or worse, the public
> API cannot be allowed to override the internal signal-safe functions
> used by TLS, because the latter are in the namespace reserved for the
> implementation whereas the former should be in the application
> namespace.

Sorry, I don't follow.

Are you suggesting two things here?

(a) Do not allow user code to override internal signal-safe allocation
    functions.

and

(b) Provide a distinct signal-safe allocation API that users can use
    and override, but which is not used by the implementation internally.

Is that what you mean?

Cheers,
Carlos.