This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][BZ #19329] Fix race between tls allocation at thread creation and dlopen
- From: Torvald Riegel <triegel at redhat dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: Ilya Palachev <i dot palachev at samsung dot com>, libc-alpha at sourceware dot org, nd at arm dot com
- Date: Fri, 22 Jan 2016 15:49:26 +0100
- Subject: Re: [PATCH][BZ #19329] Fix race between tls allocation at thread creation and dlopen
- Authentication-results: sourceware.org; auth=none
- References: <568D5E11 dot 3010301 at arm dot com> <5693CEC1 dot 5080006 at samsung dot com> <5693DB7D dot 2040302 at arm dot com> <5693DC77 dot 8080702 at arm dot com> <5694EF7E dot 70703 at samsung dot com> <56950D8D dot 1070102 at arm dot com>
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).