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

[Alexandre Oliva <aoliva at redhat dot com>]

On Nov 20, 2014, Torvald Riegel <triegel@redhat.com> wrote:

> While you're at it and have this paged in:  Are there any occurrences of
> memory accesses in the code you touched (or that you reviewed while
> doing this) that should be annotated as atomic accesses?

Yeah, plenty.  Even in the patch itself there are reindented tests for
the undecided value of l_tls_offset, retested while holding a lock.
Static TLS initialization by other threads are also an issue, although

I'm inclined to believe that such accesses are only well-defined if the
dlopen that initializes them happens-before (due to POSIX memory
synchronization operations) the access, so there's no real issue there.

There are horrible issues related with DTV resizing, but those are
MT-Safe after this patch, since the DTV is only modified by the thread
itself.  There are, however, various possibilities of error if a DTV
update is interrupted by a signal that triggers another DTV udpate.

There are various other races involving access to the dtv_slotinfo_list;
I haven't fully analyzed them enough to tell whether they're safe, let
alone to annotate them properly.

I can't guarantee the list of issues mentioned above is exhaustive;
they're just the ones that jumped at me while I investigated changes
related with the DTV implementation.

It's not in my immediate plans to tackle any of that, so please have at
it!  ;-)

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