Re: [BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit

[Alexandre Oliva <aoliva at redhat dot com>]

On Sep 24, 2016, Torvald Riegel <triegel@redhat.com> wrote:

> On Fri, 2016-09-23 at 23:52 -0300, Alexandre Oliva wrote:
>> (if it decides to update it without
>> resizing, we also have a race, but both threads end up writing the same
>> final value, which AFAIK is not so much of a problem)

> Can this still happen after your patches?

After removing (again) one of the possibly-concurrent writes, I don't
see how it could still happen, since there's only one writer to a
thread's DTV at a time: at thread creation there's one, and while the
thread is active there's another.  But that's not the result of a
thorough global analysis from scratch, it's just my intuition based on
my limited understanding of the whole TLS architecture.  If you want a
thorough analysis, I'm afraid you'll have to resort to someone else,
probably someone who speaks the same language as you, and that reasons
at the same abstraction layer as you.  I'm not that person, as our many
attempts at conversations have shown.

> ISTM that all this should become a code comment, and not just be in an
> email on the list.

It's there in the patch.

> IIUC, that's were the assumption about dlopen vs. usage comes in that
> you included in the other patch.

Yeah, that too.

> If so, this is not a data race (nor a race condition).

It is a potential data race, yes, but I'll sustain it is probably
harmless, although I know you'll take that as heresy ;-)  Please look
for the details in the other thread.

-- 
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