Re: [PATCHv3] PowerPC: Fix a race condition when eliding a lock

[Peter Bergner <bergner at vnet dot ibm dot com>]

On Tue, 2015-09-01 at 15:25 -0500, Paul E. Murphy wrote:
> 
> On 09/01/2015 02:38 PM, Peter Bergner wrote:
> > ...although looking closer, I see have the definitions we use for
> > passing in failure codes is:
> > 
> > /* Definitions used for TEXASR Failure code (bits 0:6), they need to be even
> >    because tabort. always sets the first bit.  */
> 
> This is a bad comment. This is a misinterpretation of the ISA, as you've noted,
> bit 31 is always set if tabort* is used. This makes using the conditional
> versions impractical within the TLE implementation.

I don't understand this.  All tabort* instructions, including the unconditional
tabort. set bit 31.  The only thing that tabort. does that the conditional
taborts[wd]c[i] don't do is set bits 0-7 (ie, failure code & persistent bits).



> I think the implication here is you can't trust bit 7 of texasr to deduce the
> abort code, as it could be set due to one of bits 8-11. I'm not sure if the cases
> leading bits 8-11 to get set are mutually exclusive with calling tabort. I.e is
> failure code 1 the only reserved code?

Bit 7 is supposed to be used to specify whether a transaction failure is
persistent (ie, whether we should retry the tbegin.) or not.  That bit
can be set by either a HW conflict leading to a transaction failure or
an explicit use of tabort.  It cannot be set with conditional tabort[wd]c[i]
instructions, but Adhemerval's other note seems to imply we weren't
supposed to be setting the persistent bit in this code, so using the
conditional tabort[wd]c[i] should be ok here.


Peter