Re: [PR19826] fix non-LE TLS in static programs

[Alexandre Oliva <aoliva at redhat dot com>]

On Dec  6, 2016, Florian Weimer <fweimer@redhat.com> wrote:

> On 12/06/2016 08:15 AM, Alexandre Oliva wrote:
>> On Dec  2, 2016, Florian Weimer <fweimer@redhat.com> wrote:
>> 
>>> I don't know if it is really needed,
>> 
>> No, it's wrong, it had been fixed before.
>> 
>>> I and I have no idea how to make initialization at this point safe
>> 
>> It's safe to leave that initialization out.  The checks for whether the
>> DTV needs updating are "safe enough".  As in, a thread will take care of
>> its own DTV, so there won't be races with other threads.

> But it's also called for the thread which invoked dlopen.  Does
> _dl_update_slotinfo (called from _dl_try_allocate_static_tls) take
> care of that?

Yeah, exactly.  The DTV update performed by the thread itself will take
care of it, we don't need to set up the DTV entries (other than those
for the LE module, that the code in the first patch that's not reverted
in the second takes care of) as we bump the DTV generation: that will
cause tls_get_addr to perform the update.

>> However, it's
>> not AS-Safe: if DTV resizing is interrupted by a signal whose handler
>> triggers another DTV resizing, we'll have trouble, as we always had.

> Can we block signals during DTV resizing?

That would be a reasonable way to address this problem.

>> That's one of the reasons why GD TLS is not AS-Safe.  Another is that
>> dynamic TLS blocks may have to be allocated, and we use(d?)  AS-Unsafe
>> means for the allocation.  There may be other reasons that don't come to
>> mind right now.

> We still have malloc calls in there.

*nod*.  I think we could make malloc AS-Safe by having an alternate
arena to fallback to, if the preferred arena is already locked, and if
we realize we have to fallback to the alternate arena, we block signals
before locking it and unblock them once the allocation is done.  This
would probably be better than using an alternate allocator for the DTV
and for Static TLS and whatnot.

> It's not just a problem for asynchronous signals, we do not have a way
> to report allocation failures, either.

Yeah, that's an essential consequence of deferred allocation of dynamic
TLS blocks and of per-thread DTV resizing.  We could avoid part of it by
always allocating TLS blocks statically, with some additional
synchronization at dlopen, but dealing with the DTV could be a lot more
interesting.  Ensuring one thread won't access its DTV while it's being
resized could be tricky, and ensuring the accesses by the owner thread
are well-defined after another thread resized and updated the DTV,
rather than races under the chosen memory model, could become a
performance nightmare.

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer