This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, libc-alpha at sourceware dot org
- Date: Fri, 21 Nov 2014 06:27:39 -0200
- Subject: Re: [BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit
- Authentication-results: sourceware.org; auth=none
- References: <ormw7ol1sf dot fsf at free dot home> <20141118203338 dot ECA5F2C3B25 at topped-with-meat dot com> <ord28kkvpq dot fsf at free dot home> <20141118224048 dot 600312C3B23 at topped-with-meat dot com> <orppcjotfm dot fsf at free dot home> <20141120021703 dot 86F032C3B18 at topped-with-meat dot com> <or8uj6qse8 dot fsf at free dot home> <1416507243 dot 1771 dot 56 dot camel at triegel dot csb>
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
- References:
- [BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit
- Re: [BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit
- Re: [BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit
- Re: [BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit
- Re: [BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit
- Re: [BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit
- Re: [BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit
- Re: [BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit