Re: [PR19826] fix non-LE TLS in static programs

[Alexandre Oliva <aoliva at redhat dot com>]

On Dec  6, 2016, Florian Weimer <fweimer@redhat.com> wrote:

> On 12/06/2016 07:56 AM, Alexandre Oliva wrote:
>> On Dec  2, 2016, Florian Weimer <fweimer@redhat.com> wrote:
>>> What's the status here?  It seems that Alexandre committed it on
>>> September 22nd, despite Torvald's objections.
>> 
>> No, I committed the *first* of two patches, that I'd posted on 2016-09-20.
>> https://sourceware.org/ml/libc-alpha/2016-09/msg00365.html

> I'm sorry I reconstructed the history here incorrectly.

No problem, I recall the whole thing was already confusing back when I
tried to explain it to Carlos for him to pick it up ;-)

> If I revert the change to allocatestack.c, the test case passes.

Thanks

>> What you're hitting is most likely the DTV resizing race
>> condition described in the comments there, at the '(**)' note.

> It's not even a race.  The test case serializes DTV access externally,
> and still fails.  So the comment about a race is rather misleading.

Ah, sorry, I haven't looked at the testcase yet, but from your
description, I suppose you eliminated the race.  We still access the DTV
past the end, though.  Earlier (before the zeroth patch installed on
March, 2015), we had a limit on the Static TLS modid, so that the DTV
entry initialization wouldn't write past the end of the DTV.  That patch
lifted that limit, and removed the DTV entry initialization from that
point.

The first patch (2016-09-20's) mistakenly brought that code back.  We
have to revert that.  We should probably mention the writing past the
end of the DTV in the comments too.

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer