linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Breno Leitao <leitao@debian.org>
To: Michael Neuling <mikey@neuling.org>, linuxppc-dev@lists.ozlabs.org
Cc: ldufour@linux.vnet.ibm.com, gromero@linux.vnet.ibm.com
Subject: Re: [RFC PATCH 10/11] powerpc/tm: Set failure summary
Date: Thu, 27 Sep 2018 17:52:29 -0300	[thread overview]
Message-ID: <85a2de6d-6cb5-6052-252e-858e61eb00ab@debian.org> (raw)
In-Reply-To: <7647a2d788ceb979e6de8bb8bb988f4d37fb1877.camel@neuling.org>

Hi Mikey,

On 09/18/2018 02:50 AM, Michael Neuling wrote:
> On Wed, 2018-09-12 at 16:40 -0300, Breno Leitao wrote:
>> Since the transaction will be doomed with treckpt., the TEXASR[FS]
>> should be set, to reflect that the transaction is a failure. This patch
>> ensures it before recheckpointing, and remove changes from other places
>> that were calling recheckpoint.
> 
> TEXASR[FS] should be set by the reclaim. 

Do you mean that the CPU should set TEXASR[FS] when treclaim is called, or,
that the tm_reclaim?

Looking at the ISA, I didn't see TEXASR[FS] being set automatically when a
reclaim happens, although, I see it needs TEXASR[FS] to be set when executing
a trecheckpoint, otherwise it will cause a TM Bad Thing.

That is why I am forcing TEXASR[FS]=1 to doom the transaction so we can
recheckpoint it, but it seems I understood this wrongly.

> I don't know why you'd need to set this
> explicitly in process.c. The only case is when the user supplies a bad signal
> context, but we should check that in the signals code, not process.c
> 
> Hence I think this patch is wrong.
> 
> Also, according to the architecture, TEXASR[FS] HAS TO BE SET on trecheckpoint
> otherwise you'll get a TM Bad Thing. You should say that rather than suggesting
> it's because the transaction is doomed. It's ilqlegal to not do it. That's why we
> have this check in arch/powerpc/kernel/tm.S.

When you say "HAS TO BE SET", do you mean that the hardware will set it and
we shouldn't care about this flag? Thus, if I am hitting EMIT_BUG_ENTRY, it
means my TEXASR was messed somehow?

Thank you

  reply	other threads:[~2018-09-27 21:13 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-12 19:40 [RFC PATCH 00/11] New TM Model Breno Leitao
2018-09-12 19:40 ` [RFC PATCH 01/11] powerpc/tm: Reclaim transaction on kernel entry Breno Leitao
2018-09-18  1:31   ` Michael Neuling
2018-09-27 20:28     ` Breno Leitao
2018-09-27 20:28       ` Breno Leitao
2018-09-12 19:40 ` [RFC PATCH 02/11] powerpc/tm: Reclaim on unavailable exception Breno Leitao
2018-09-12 19:40 ` [RFC PATCH 03/11] powerpc/tm: Recheckpoint when exiting from kernel Breno Leitao
2018-09-12 19:40 ` [RFC PATCH 04/11] powerpc/tm: Always set TIF_RESTORE_TM on reclaim Breno Leitao
2018-09-12 19:40 ` [RFC PATCH 05/11] powerpc/tm: Function that updates the failure code Breno Leitao
2018-09-17  5:29   ` Michael Neuling
2018-09-18  1:29   ` Michael Neuling
2018-09-27 20:58     ` Breno Leitao
2018-09-28  5:27       ` Michael Neuling
2018-09-18  3:27   ` Michael Neuling
2018-09-12 19:40 ` [RFC PATCH 06/11] powerpc/tm: Refactor the __switch_to_tm code Breno Leitao
2018-09-18  4:04   ` Michael Neuling
2018-09-27 20:48     ` Breno Leitao
2018-09-12 19:40 ` [RFC PATCH 07/11] powerpc/tm: Do not recheckpoint at sigreturn Breno Leitao
2018-09-18  5:32   ` Michael Neuling
2018-09-12 19:40 ` [RFC PATCH 08/11] powerpc/tm: Do not reclaim on ptrace Breno Leitao
2018-09-18  5:36   ` Michael Neuling
2018-09-27 21:03     ` Breno Leitao
2018-09-28  5:36       ` Michael Neuling
2018-09-30 23:51         ` Breno Leitao
2018-10-01  0:34           ` Michael Neuling
2018-09-12 19:40 ` [RFC PATCH 09/11] powerpc/tm: Do not restore default DSCR Breno Leitao
2018-09-18  5:41   ` Michael Neuling
2018-09-27 20:51     ` Breno Leitao
2018-09-28  5:03       ` Michael Neuling
2018-09-12 19:40 ` [RFC PATCH 10/11] powerpc/tm: Set failure summary Breno Leitao
2018-09-18  5:50   ` Michael Neuling
2018-09-27 20:52     ` Breno Leitao [this message]
2018-09-28  5:17       ` Michael Neuling
2018-09-12 19:40 ` [RFC PATCH 11/11] selftests/powerpc: Adapt the test Breno Leitao
2018-09-18  6:36   ` Michael Neuling
2018-09-27 20:57     ` Breno Leitao
2018-09-28  5:25       ` Michael Neuling
2018-10-01 17:50         ` Breno Leitao
2018-09-17  5:25 ` [RFC PATCH 00/11] New TM Model Michael Neuling
2018-09-27 20:13   ` Breno Leitao
2018-09-27 20:13     ` Breno Leitao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=85a2de6d-6cb5-6052-252e-858e61eb00ab@debian.org \
    --to=leitao@debian.org \
    --cc=gromero@linux.vnet.ibm.com \
    --cc=ldufour@linux.vnet.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mikey@neuling.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).