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

[Ilya Palachev <i dot palachev at samsung dot com>]

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