[PATCH 4/6] Do not call _xend if no transaction is active.

[Andi Kleen]

Dominik Vogt <vogt@linux.vnet.ibm.com> writes:
>
> This patch is _not_ about what happens when the user unlocks an
> unlocked lock.  It is about what happens when the user unlocks a
> mutex that has been elided, but when at the time of unlock() no
> transaction is open.

That's unlocking a free lock: undefined.

> If all instructions are executed in a row, this is correct code,
> regardless of whether elision is available in foo, in glibc or
> both or not at all.  Now consider this:
>
>   if (some_condition) goto side_entrance
>     foo_lock(x);
>   side_entrance:
>     phtread_mutex_lock(m);
>     foo_unlock(x);
>     phtread_mutex_unlock(m);
>
> Under some_condition, the initial foo_lock(x) is skipped.  Now
> mutex_lock() starts a transaction, foo_unlock detects an unlocked
> lock and assumes it is elided and calls _xend() and thus commits
> the transaction.  The final mutex_unlock() would try to xend the
> assumed transaction and crash.

You're unlocking a free lock in foo. Which I would argue
is broken.

If you want to do that you have to keep track of it somehow
else, not make everyone slower in pthreads.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only