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: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>
- Cc: <i dot palachev at samsung dot com>, "triegel at redhat dot com" <triegel at redhat dot com>, <nd at arm dot com>
- Date: Tue, 12 Jan 2016 11:02:47 +0000
- Subject: Re: [PATCH][BZ #19329] Fix race between tls allocation at thread creation and dlopen
- Authentication-results: sourceware.org; auth=none
- Nodisclaimer: True
- References: <568D5E11 dot 3010301 at arm dot com> <5693D908 dot 8090104 at arm dot com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
On 11/01/16 16:32, Szabolcs Nagy wrote:
Further issues:
dlclose also modifies the slotinfo list in unsafe ways and i don't
immediately see a lockfree way to synchronize that with thread
creation. (using the GL(dl_load_lock) at thread creation does not work
because it can deadlock if pthread_create is called from a ctor while
dlopen holds the lock.)
i.e. this patch assumes dlclose is not called concurrently with
pthread_create.
dlopen holding the lock during ctors is observably broken, i filed
https://sourceware.org/bugzilla/show_bug.cgi?id=19448
if that's fixed then pthread_create can grab the lock too and then
dlopen/dlclose/pthread_create are trivially synchronized without any
atomics.
the problem of non-as-safety of tls access still remains, but that's
a separate issue.