This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]