This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] [BZ #19329] Fix race during concurrent dlopen and pthread_create
- From: Ilya Palachev <i dot palachev at samsung dot com>
- To: Szabolcs Nagy <nsz at port70 dot net>
- Cc: libc-alpha at sourceware dot org, triegel at redhat dot com, siddhesh dot poyarekar at linaro dot org, szabolcs dot nagy at arm dot com, v dot barinov at samsung dot com
- Date: Wed, 30 Dec 2015 12:08:36 +0300
- Subject: Re: [PATCH] [BZ #19329] Fix race during concurrent dlopen and pthread_create
- Authentication-results: sourceware.org; auth=none
- References: <1451385533-9485-1-git-send-email-i dot palachev at samsung dot com> <20151229180603 dot GW23362 at port70 dot net>
On 29.12.2015 21:06, Szabolcs Nagy wrote:
thanks
i have a different fix for this, but even that's not complete.
there are several globals (related to tls) accessed in dlopen and
pthread_create without synchronization, those should be fixed
even if they haven't caused observable problems yet.
Very interesting, so we're waiting for your implementation.
this approach changes behaviour:
previously when a new dso was loaded all of its dependencies got
the same generation number: GL(dl_tls_generation)+1
with the patch each loaded dso increments the generation counter.
(so at least the overflow detection needs to be different)
Sorry, now I see the mistake that has been done.
i don't know if this is a problem, but my approach is conservative
and tries to fix the issue in _dl_allocate_tls_init by only
considering tls for which the generation counter is already updated.
(slotinfo etc also has to use atomics to make the changes visible
to other threads)
i can only post my fix after my holiday (sometime on the first week
of jan), but there still seem to be some fundamental issues with the
design (i think these races can be fixed, but the async-signal safe
allocation of tls will require significant changes here and without
that tls access from signal handlers is broken)