[PATCH][BZ #19329] Fix race between tls allocation at thread creation and dlopen

[Ilya Palachev]

On 11.01.2016 19:46, Szabolcs Nagy wrote:
> On 11/01/16 16:42, Szabolcs Nagy wrote:
>> On 11/01/16 15:48, Ilya Palachev wrote:
>>> How can you prove that it is working if the assertion that was 
>>> failing is now just deleted from the code?
>>
>> i can only prove that the assertion is wrong by
>> analysing the code: the condition it verifies
>> cannot be enforced with the current design.
>>
>> removing it is harmless since the slotinfo entries
>> are lazy initialized.
>>

Thanks for explanation.
Do you mean that slotinfo entries are lazy initialized in 
_dl_update_slotinfo ?

>
> actually this is not true if dlclose may be called
> concurrently with pthread_create as i noted in my
> new patch description.
>
> i don't know how to protect against that.

Does _dl_update_slotinfo has support for updating DTV's of other threads 
in case when some thread called dlclose?
As I can see dlclose just sets map pointer to NULL and increments the 
generation counter:

1. In remove_slotinfo function:

           listp->slotinfo[idx - disp].gen = GL(dl_tls_generation) + 1;
           listp->slotinfo[idx - disp].map = NULL;

2. In _dl_close_worker function:
   /* If we removed any object which uses TLS bump the generation 
counter.  */
   if (any_tls)
     {
       if (__glibc_unlikely (++GL(dl_tls_generation) == 0))
         _dl_fatal_printf ("TLS generation counter wrapped!  Please 
report as described in "REPORT_BUGS_TO".\n");

       if (tls_free_end == GL(dl_tls_static_used))
         GL(dl_tls_static_used) = tls_free_start;
     }

You have just fixed such memory accesses with atomic_load_acquire and 
atomic_store_release.
Won't these atomics be enough to fix races with dlclose? Or am I missing 
something?

Or you just would like to fill separate bug report for dlclose race?

--
Best regards,
Ilya Palachev