This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PR18457] Don't require rtld lock to compute DTV addr for static TLS
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>, libc-alpha at sourceware dot org
- Date: Tue, 09 Jun 2015 19:32:21 -0300
- Subject: Re: [PR18457] Don't require rtld lock to compute DTV addr for static TLS
- Authentication-results: sourceware.org; auth=none
- References: <orvbf5ffyt dot fsf at livre dot home> <20150603152448 dot GC32684 at spoyarek dot pnq dot redhat dot com> <5570819F dot 3070902 at redhat dot com> <orr3pqdbqm dot fsf at livre dot home> <5571E6E9 dot 50604 at redhat dot com> <orr3pqarri dot fsf at livre dot home> <1433710090 dot 21461 dot 418 dot camel at triegel dot csb> <oregllzk87 dot fsf at livre dot home> <1433851553 dot 21461 dot 561 dot camel at triegel dot csb>
On Jun 9, 2015, Torvald Riegel <triegel@redhat.com> wrote:
> On Mon, 2015-06-08 at 23:30 -0300, Alexandre Oliva wrote:
>> On Jun 7, 2015, Torvald Riegel <triegel@redhat.com> wrote:
>> > Also, it sounds as if any thread concurrent with the dlopen could only
>> > actually create a concurrent access if dlopen has the lock already --
>> > but that doesn't seem to be a requirement based on the "spin"
>> > example/analogy you gave.
>>
>> There are two roles dlopen plays here:
>>
>> 1. loading the module that defines the TLS variable
>>
>> 2. applying TLS replications to modules that reference the TLS variable
>>
>> It might turn out that 1. and 2. are performed under a single rtld lock
>> taking, and a subsequent dlopen could bring in additional references to
>> TLS variables.
> I can't follow you; I don't see how it addresses my comment.
rtld's role 1 is analogous to init in the electron spin example.
rtld's role 2 is analogous to make_positive in the electron spin
example.
In some cases, rtld roles 1 and 2 are performed without releasing the
lock. In this case, no concurrent accesses are possible, because nobody
else can have the pointer returned by init, to pass to the other
functions, before init returns.
Now, in case rtld's role 2 is performed separately, as in a subsequent
dlopen (analogous to make_positive), there may be concurrent
tls_get_addr accesses (analogous to concurrent positive_p calls). At
this point, role 1 has already released the lock and set up the module
defining the TLS variable and possibly processed some dynamic TLS access
model relocations (analogous to init returning), so there is room for
concurrency between those accesses and a subsequent dlopen, that may or
may not require the variable to be placed in static TLS.
Does this clarify how my response addresses your comment?
--
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