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

[Paul E. Murphy]

On 09/01/2015 03:46 PM, Adhemerval Zanella wrote:
> Indeed the 'odd' comment does not make sense and we should just remove it
> (I misread texasr definition).  My initial idea was define some codes
> that set the persistent failures and some that do not.  I think I best
> approach would be:
> 
> /* tabort will set TEXASR(0:31) = ((_ABORT_LOCK_BUSY & 0xff) << 24) | 0x1
>    and the TEXASR persistent bit is bit 25 (32-7).  Only the syscall
>    code means a persistent error that should trigger a default lock
>    acquisition.  */
> #define _ABORT_SYSCALL         0x1   /* Syscall issued.  */
> #define _ABORT_LOCK_BUSY       0x2   /* Lock already used.  */
> #define _ABORT_NESTED_TRYLOCK  0x4   /* Write operation in trylock.  */

The kernel defines several abort codes, we'll want to work with them, or
recycle them as needed.

I'm not convinced any of the existing codes should be non-persistent:

A pthread_mutex_trylock attempt within an elided pthread_mutex_lock is
guaranteed to fail try_tbegin times if there is no contention on the lock.
Aborts get increasingly expensive as you increase the amount of speculative
execution.

A busy lock likely indicates contention in the critical section which
does not benefit from elision, I'd err on the side of a persistent
failure.