Re: [PATCH] Use IE model for static variables in glibc

[OndÅej BÃlka <neleai at seznam dot cz>]

On Thu, Jul 09, 2015 at 11:35:45PM +0530, Siddhesh Poyarekar wrote:
> The recently introduced TLS variables in the thread-local destructor
> implementation (__cxa_thread_atexit_impl) used the default GD access
> model, resulting in a call to __tls_get_addr.  This causes a deadlock
> with recent changes to the way TLS is initialized because DTV
> allocations are delayed and hence despite knowing the offset to the
> variable inside its TLS block, the thread has to take the global rtld
> lock to safely update the TLS offset.
> 
> This causes deadlocks when a thread is instantiated and joined inside
> a destructor of a dlopen'd DSO.  The correct long term fix is to
> somehow not take the lock, but that will need a lot deeper change set
> to alter the way in which the big rtld lock is used.
> 
> Instead, this patch just eliminates the call to __tls_get_addr for the
> thread-local variables inside libc.so.  The variables changed are the
> 3 in cxa_thread_atexit and the strerror thread-local variable.
> 
> There were concerns that the static storage for TLS is limited and
> hence we should not be using it.  Additionally, dynamically loaded
> modules may result in libc.so looking for this static storage pretty
> late in static binaries.  Both concerns are valid when using TLSDESC
> since that is where one may attempt to allocate a TLS block from
> static storage for even those variables that are not IE.  They're not
> very strong arguments for the traditional TLS model though, since it
> assumes that the static storage would be used sparingly and definitely
> not by default.  Hence, for now this would only theoretically affect
> ARM architectures.
> 
> The impact is hence limited to statically linked binaries that dlopen
> modules that in turn load libc.so, all that on arm hardware.  It seems
> like a small enough impact to justify fixing the larger problem that
> currently affects everything everywhere.
> 
If we are at dlopen what happens if user uses older glibc version?

Otherwise increased storage doesn't matter much, you could bump reserved
size if necessary. Only other use of nonie tls is 18 bytes in inet_ntoa
to return value.