[PATCH] Async signal safe TLS accesses

[Rich Felker]

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.

Rich