This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][BZ 18743] PowerPC: Fix a race condition when eliding a lock
- From: Peter Bergner <bergner at vnet dot ibm dot com>
- To: Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>
- Cc: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, libc-alpha at sourceware dot org, Torvald Riegel <triegel at redhat dot com>
- Date: Fri, 21 Aug 2015 10:43:27 -0500
- Subject: Re: [PATCH][BZ 18743] PowerPC: Fix a race condition when eliding a lock
- Authentication-results: sourceware.org; auth=none
- References: <1438274936-26493-1-git-send-email-tuliom at linux dot vnet dot ibm dot com> <55BA703D dot 7010303 at linaro dot org> <874mkl3wtq dot fsf at totoro dot lan> <1440103701 dot 5188 dot 46 dot camel at otta> <874mjssm7p dot fsf at totoro dot lan>
On Fri, 2015-08-21 at 12:19 -0300, Tulio Magno Quites Machado Filho wrote:
> Peter Bergner <bergner@vnet.ibm.com> writes:
> > I completely agree we need a barrier here, so I will fix that. The question
> > I'm starting to wonder, is do we need more than just a memory barrier or
> > do we need a complete optimization barrier, so no code (even scalar code)
> > will move past the __builtin_tbegin() (and other HTM builtins)?
> > ...
> > observable if one or more of the transactions succeeds. Torvald,
> > Adhemerval and Tulio, do you guys agree with that assessment?
>
> I agree with you.
> The compiler shouldn't move instructions that affect memory or any of the
> checkpointed registers.
Interestingly, Intel seems to have a similar issue:
https://gcc.gnu.org/PR63672
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02999.html
..although, Andi only tried adding memory barriers to the builtins
and not full optimization barriers. It seems the above patch never
made it into trunk.
Peter