Re: nptl/tst-stack4 failure

[Florian Weimer <fweimer at redhat dot com>]

On 11/16/2016 04:52 PM, Siddhesh Poyarekar wrote:
> On Wednesday 16 November 2016 09:09 PM, Florian Weimer wrote:
> > The nptl/tst-stack4 test fails reliably on several architectures for me
> > (ppc, ppc64, aarch64).  I'm trying to figure out what's going on.
>
> I saw this yesterday and bisected it to this commit:
>
> =================
> commit 17af5da98cd2c9ec958421ae2108f877e0945451
> Author: Alexandre Oliva <aoliva@redhat.com>
> Date: Wed Sep 21 22:01:16 2016 -0300
>
> [PR19826] fix non-LE TLS in static programs

Thanks, I was approaching this commit as well, I think.

> I had planned to look at it later in the week but if you have the time
> then please feel free to pick it up.

I'm not sure what's going on there.  I don't know what the expectations 
for this code are.  Clearly, __tls_get_addr has to be async-signal-safe, 
but it calls update_get_addr and tls_get_addr_tail, and the latter 
acquires dl_load_lock.

There is an acquire load on dl_tls_max_dtv_idx in dl-tls.c, but it's 
never written in an atomic fashion.  It seems that nptl/allocatestack.c 
calls into the elf/dl-tls.c code without acquiring any rtld locks. 
Considering that we reuse modid slots after a dlclose, this can't be 
right, I think.

Florian