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

[Torvald Riegel]

On Fri, 2016-01-22 at 18:32 +0000, Szabolcs Nagy wrote:
> On 22/01/16 14:49, Torvald Riegel wrote:
> > On Tue, 2016-01-12 at 14:28 +0000, Szabolcs Nagy wrote:
> >> tl;dr: if your libc has non-noop dlclose it must use a
> >> global lock in dlopen/dlclose/thread creation/tls access
> >> and user code must not run while that lock is held
> >> (e.g. signals must be blocked)
> >
> > Depending on what the non-noop functionality is, it might be possible to
> > still implement this in a nonblocking way (so you avoid the blocking
> > sync vs. signals and reentrancy issue).
> 
> the non-noop functionality is that dlclose frees
> memory that pthread_create and tls access may look at
> (the link_map of a dso).
> 
> i guess lock-free garbage collection is a possibility
> (e.g. refcounting, except tls access cannot call free
> so it's not entirely trivial.)

So we need to reach a quiescent state (eg, like RCU has to).
Not trivial, but it seems releasing memory can be deferred to a later
time, and it does not need to be performed by a particular thread.  So
one can just build a list of things to be freed, and the first thread
that can do it just does it.