[PATCH] Async signal safe TLS accesses
Rich Felker
dalias@aerifal.cx
Tue Sep 24 02:57:00 GMT 2013
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...)
Rich
More information about the Libc-alpha
mailing list