Re: [PATCH][BZ 18572][ARM] Fix lazy TLSDESC race on arm

[Rich Felker <dalias at libc dot org>]

On Thu, Nov 12, 2015 at 11:31:46AM +0000, Szabolcs Nagy wrote:
> Lazily initialized TLS descriptors have a race on ARM, so
> concurrent TLS access can cause crashes with -mtls-dialect=gnu2.
> 
> See the fix and description for AArch64:
> https://sourceware.org/ml/libc-alpha/2015-06/msg00496.html
> 
> Differences compared to AArch64:
> 
> - Various versions of ARM have different synchronization methods,
>   defined a DMB() macro that selects the right memory barrier at
>   compile-time (since compiler builtins are not available in asm
>   and it seems glibc does not do runtime dispatch).
> 
> - tls descriptor is (arg,f) on arm instead of (f,arg), this makes
>   the "load f again with acquire mo" solution of AArch64 less
>   attractive. (LDA on AArch32 only works with 0 offset and with
>   an extra ADD the armv8 case would need more special casing with
>   questionable benefits).
> 
> - the argument is different (symbol table index instead of a
>   pointer to the relocation entry) so symbol lookup is different
>   and there is no simple way to have common tlsdesc.c across
>   different archs.
> 
> - _dl_tlsdesc_undefweak does not access the argument so it needs
>   no synchronization.
> 
> The C code uses atomic_store_release for lazy initialization and
> the asm uses DMB in the resolvers: every tls access will go
> through an extra barrier (which must have a performance impact).

I think the right solution is to deprecate and eventually remove lazy
tlsdesc resolvers, but we could start by having a macro that sysdep
files can define on affected archs to disable lazy resolution. Putting
a barrier in every tlsdesc access obviously makes it much worse than
non-tlsdesc GD model and defeats the whole purpose of tlsdesc, no?

Rich