This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH][BZ #19329] Fix race between tls allocation at thread creation and dlopen
- From: Ilya Palachev <i dot palachev at samsung dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, libc-alpha at sourceware dot org
- Cc: nd at arm dot com
- Date: Tue, 12 Jan 2016 15:20:14 +0300
- 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>
On 11.01.2016 19:46, Szabolcs Nagy wrote:
On 11/01/16 16:42, Szabolcs Nagy wrote:
On 11/01/16 15:48, Ilya Palachev wrote:
How can you prove that it is working if the assertion that was
failing is now just deleted from the code?
i can only prove that the assertion is wrong by
analysing the code: the condition it verifies
cannot be enforced with the current design.
removing it is harmless since the slotinfo entries
are lazy initialized.
Thanks for explanation.
Do you mean that slotinfo entries are lazy initialized in
actually this is not true if dlclose may be called
concurrently with pthread_create as i noted in my
new patch description.
i don't know how to protect against that.
Does _dl_update_slotinfo has support for updating DTV's of other threads
in case when some thread called dlclose?
As I can see dlclose just sets map pointer to NULL and increments the
1. In remove_slotinfo function:
listp->slotinfo[idx - disp].gen = GL(dl_tls_generation) + 1;
listp->slotinfo[idx - disp].map = NULL;
2. In _dl_close_worker function:
/* If we removed any object which uses TLS bump the generation
if (__glibc_unlikely (++GL(dl_tls_generation) == 0))
_dl_fatal_printf ("TLS generation counter wrapped! Please
report as described in "REPORT_BUGS_TO".\n");
if (tls_free_end == GL(dl_tls_static_used))
GL(dl_tls_static_used) = tls_free_start;
You have just fixed such memory accesses with atomic_load_acquire and
Won't these atomics be enough to fix races with dlclose? Or am I missing
Or you just would like to fill separate bug report for dlclose race?