Re: Libitm issues porting to POWER8 HTM

[Torvald Riegel <triegel at redhat dot com>]

On Fri, 2013-06-14 at 19:44 -0500, Peter Bergner wrote:
> I'm currently implementing support for hardware transactional memory in
> the rs6000 backend for POWER8.  Things seem to be mostly working, but I
> have run into a few issues I'm wondering whether other people are seeing.
> 
> For me, all of the libitm execution test cases in libitm/testsuite/libitm.c/
> compile and execute without error, except for reentrant.c, which hangs for me.
> My gdb hasn't been ported to support HTM on Power yet, so debugging has been
> slow, but what I've learned is, that my tbegin. instruction succeeds, but I
> fail the test (meaning someone has the write lock) at beginend.cc:200:
> 
>     if (unlikely(serial_lock.is_write_locked()))
>       htm_abort();
> 
> ...so we abort the transaction.  The failure is not persistent, so we do
> not break out of the loop due to:
> 
>     if (!htm_abort_should_retry(ret))
>       break;
> 
> We then fall into the following code, where we hang trying to get the
> read lock:
> 
>     serial_lock.read_lock(tx);
> 
> I have yet to track down who has the write lock and why, but I am working
> towards that.  Talking with Andreas, he said he is seeing the same failure
> on S390, so I'm wondering whether this might be a generic libitm issue
> and it might hit Intel too.

I think that this is a bug in libitm's HTM fastpath.  What I suppose
happens is that we have a relaxed outermost transaction that executes
unsafe code (see reentrant.c), thus switches to serial-irrevocable mode,
and then tries to start a nested transaction.  The nested txn then
observes in the HTM fastpath that there is a serial-mode txn already,
but it never checks whether it is enclosed in an already serial
outermost transaction.

> Does anyone know whether this executes correctly
> on Intel hardware with RTM?

I don't know currently, but I suppose the bug should trigger there too
(unless, for some reason, the nested txn always aborts immediately with
RTM).

> I'll note that if I hack the call to
> htm_abort_should_retry(ret) so that we break of of the loop and fallback
> to SW TM, then the test case executes correctly.

That matches what I suppose the bug is.

Please feel free to create a bug report.  I will work on a patch.

Torvald