This is the mail archive of the
mailing list for the glibc project.
Why do Glibc needs to hold a lock in tls_get_addr_tail?
- From: Maxim Ostapenko <chefmax7 at gmail dot com>
- To: libc-help at sourceware dot org
- Date: Tue, 20 Dec 2016 12:55:38 +0300
- Subject: Why do Glibc needs to hold a lock in tls_get_addr_tail?
- Authentication-results: sourceware.org; auth=none
Hi Glibc developers,
I had several issues with TLS on our system (BZ #17620 and BZ #18457
actually) and fortunately was able to fix them with corresponding
However, during investigation, I tried to understand details of TLS
implementation in Glibc (I was looking to current trunk) and was
confused by some code paths.
In particular, I can't understand following comment in
static void *
tls_get_addr_tail (GET_ADDR_ARGS, dtv_t *dtv, struct link_map *the_map)
/* Make sure that, if a dlopen running in parallel forces the
variable into static storage, we'll wait until the address in the
static TLS block is set up, and use that. If we're undecided
yet, make sure we make the decision holding the lock as well. */
if (__glibc_unlikely (the_map->l_tls_offset
if (__glibc_likely (the_map->l_tls_offset == NO_TLS_OFFSET))
the_map->l_tls_offset = FORCED_DYNAMIC_TLS_OFFSET;
else if (__glibc_likely (the_map->l_tls_offset
How could it be that dynamic linker resolves thread local symbol to a
library that still not loaded (dlopen still running)?
The only case I can imagine here is something like this:
dlopen ("libfoo.so". RTLD_GLOBAL);
sym = dlsym (RTLD_DEFAULT, "foo");
*sym = ...
where "foo" is defined in libfoo.so library.
Is that the case we need to protect with lock inside
tls_get_addr_tail? Or maybe there is another test case for this code
path (perhaps in Glibc testsuite)?