RFR(S) 8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM critical section

[Volker Simonis]

Hi Gustavo,

thanks for the new webrev. It looks good in general. However I think we
must check for uc being NULL. Something like:

+  if (uc && uc->uc_link) {+    ucontext_t* second_uc = uc->uc_link;+

I also didn't fully understand the comment about LSB/MSB. Doesn't it mean
that we need to compare the msr register against different masks depending
on the endianess?

Regards,
Volker


On Thu, Aug 4, 2016 at 9:36 AM, Gustavo Romero <gromero at linux.vnet.ibm.com>
wrote:

> Hi Martin,
>
> Thanks a lot for reviewing.
>
> On 03-08-2016 10:17, Doerr, Martin wrote:
> > 1. A future C++ compiler or runtime code may use HTM, too. Should your
> new code get invoked in such a case? Or is it only for transactions which
> were started in the code cache (UseRTMLocking)?
> I see. Initially I was just thinking in the case of a transaction started
> in the code cache, but it's fine for a runtime code to use HTM and generate
> a signal in the middle of it as we simply return the control back to the
> HTM abort handler (new webrev below).
>
> For a C++ compiler with TM (PPC64), I'm unable to foresee the final
> implementation of the atomic blocks and how it would affect the signal
> handler in the specific case of PPC64 (where we have two contexts due to
> the additional suspend TM state). Anyway I believe the abortion in an
> atomic block would yield an event similar to the runtime code, so in
> that case it's already covered.
>
>
> > 2. I was wondering why you only check for zombie_not_entrant. There are
> many cases in which a signal may occur during a transaction (e.g. implicit
> null check, range check, stack overflow check, safepoint poll, ... and
> possibly more in the future). What about them? I guess continuing execution
> in the context of the 'treclaim'ed transaction is incorrect.
> Sorry, I forgot all those cases, hence yes, it's incorrect to continue the
> execution in the second context (or speculated state).
>
>
> > 3. I think reporting errors which occur during transactions is cool. But
> if it's too complex, I could live without it. Other platforms don't support
> this either (they just abort by hardware).
> Yes, I was really focused on finding a way to report errors that could
> occur during transactions. I think it would be cool, nonetheless I agree,
> it's too complex (also as an implication of all the cases mentioned in 2.).
>
>
> > I was not involved in the earlier discussion. Maybe I missed something.
> No, you did not miss anything. Thomas raised the question on if two
> contexts exist, then which one would be correct/valid for error reporting.
> My try on using the second context to report precisely the root cause of an
> abortion was inspired by his question.
>
> new webrev:
> http://81.de.7a9f.ip4.static.sl-reverse.com/8162369/v2
>
> Thanks and best regards,
> Gustavo
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20160804/924b02a4/attachment.html>