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: Torvald Riegel <triegel at redhat dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Florian Weimer <fw at deneb dot enyo dot de>, Andreas Schwab <schwab at suse dot de>, Richard Henderson <rth at twiddle dot net>, Alan Modra <amodra at gmail dot com>, Roland McGrath <roland at hack dot frob dot com>, codonell at redhat dot com, libc-alpha at sourceware dot org, rth at redhat dot com
- Date: Fri, 30 Sep 2016 11:22:18 +0200
- Subject: Re: [BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit
- Authentication-results: sourceware.org; auth=none
- References: <ord28kkvpq.fsf@free.home> <orppcjotfm.fsf@free.home> <20141120021703.86F032C3B18@topped-with-meat.com> <or8uj6qse8.fsf@free.home> <oroas0mzri.fsf@free.home> <orlhmgyall.fsf@free.home> <orlhlgdb8d.fsf@livre.home> <ormw411b25.fsf@livre.home> <20150304050529.GD26435@bubble.grove.modra.org> <20150304110430.GE26435@bubble.grove.modra.org> <ory4nb6mmc.fsf@livre.home> <orlhja7vgs.fsf@livre.home> <55072871.3060104@twiddle.net> <oregoomeda.fsf@livre.home> <mvm60px9pyi.fsf@hawking.suse.de> <or60pmod4r.fsf@livre.home> <87lgyi9wq3.fsf@mid.deneb.enyo.de> <orzimyknzx.fsf@livre.home> <1474714376.30192.347.camel@localhost.localdomain> <or8tufljgv.fsf@livre.home> <1475148450.30192.461.camel@localhost.localdomain> <orlgyagy14.fsf@livre.home>
On Thu, 2016-09-29 at 19:07 -0300, Alexandre Oliva wrote:
> What I know about these topics would allow me to make numerous other
> claims, of course. But what would the point be of my spelling any of
> them out? You wouldn't believe them anyway! Even if I said I'd made a
> thorough analysis, would you trust it?
What I asked for is that you make it clear if you are not confident in a
comment you add. Of course, I'd trust such a comment less than one that
you are confident in.
>
> >> > 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,
>
> > I'm saying that when making the assumption, which is essentially a
> > precondition we (should) specify, this isn't a data race. If violating
> > the precondition, then that's already undefined behavior, but a fault of
> > the caller.
>
> Are you saying it ceases to be a data race just because some earlier
> precondition failed to be observed? I don't think I agree with that.
I would not classify it as a data race in the code because we make
statements about the code based on what it's supposed to do. If the
caller violates the preconditions, everything can happen.
Nonetheless, when speculating about what would happen if the caller
would be allowed to call in a way that violates the precondition, then
we would say that there's a data race there. However, speculating about
possible behavior that violates preconditions in code comments is just
confusing IMO, unless it's explicitly stated (ie, that this is
essentially a thought experiment).
- References:
- 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
- Re: [BZ#17090/17620/17621]: fix DTV race, assert, and DTV_SURPLUS Static TLS limit