All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michal Suchánek" <msuchanek@suse.de>
To: Breno Leitao <leitao@debian.org>
Cc: linuxppc-dev@lists.ozlabs.org, mikey@neuling.org,
	Stable <stable@vger.kernel.org>,
	gromero@linux.vnet.ibm.com
Subject: Re: [PATCH 3/4] powerpc/tm: Unset MSR[TS] if not recheckpointing
Date: Fri, 7 Dec 2018 14:48:38 +0100	[thread overview]
Message-ID: <20181207144838.4f0382c6@naga.suse.cz> (raw)
In-Reply-To: <1543263121-9590-3-git-send-email-leitao@debian.org>

On Mon, 26 Nov 2018 18:12:00 -0200
Breno Leitao <leitao@debian.org> wrote:

> There is a TM Bad Thing bug that can be caused when you return from a
> signal context in a suspended transaction but with ucontext MSR[TS] unset.
> 
> This forces regs->msr[TS] to be set at syscall entrance (since the CPU
> state is transactional). It also calls treclaim() to flush the transaction
> state, which is done based on the live (mfmsr) MSR state.
> 
> Since user context MSR[TS] is not set, then restore_tm_sigcontexts() is not
> called, thus, not executing recheckpoint, keeping the CPU state as not
> transactional. When calling rfid, SRR1 will have MSR[TS] set, but the CPU
> state is non transactional, causing the TM Bad Thing with the following
> stack:
> 

Works for me on Linux 4.4 and 4.12

Tested-by: Michal Suchánek <msuchanek@suse.de>

Thanks

WARNING: multiple messages have this Message-ID (diff)
From: "Michal Suchánek" <msuchanek@suse.de>
To: Breno Leitao <leitao@debian.org>
Cc: mikey@neuling.org, linuxppc-dev@lists.ozlabs.org,
	Stable <stable@vger.kernel.org>,
	gromero@linux.vnet.ibm.com
Subject: Re: [PATCH 3/4] powerpc/tm: Unset MSR[TS] if not recheckpointing
Date: Fri, 7 Dec 2018 14:48:38 +0100	[thread overview]
Message-ID: <20181207144838.4f0382c6@naga.suse.cz> (raw)
In-Reply-To: <1543263121-9590-3-git-send-email-leitao@debian.org>

On Mon, 26 Nov 2018 18:12:00 -0200
Breno Leitao <leitao@debian.org> wrote:

> There is a TM Bad Thing bug that can be caused when you return from a
> signal context in a suspended transaction but with ucontext MSR[TS] unset.
> 
> This forces regs->msr[TS] to be set at syscall entrance (since the CPU
> state is transactional). It also calls treclaim() to flush the transaction
> state, which is done based on the live (mfmsr) MSR state.
> 
> Since user context MSR[TS] is not set, then restore_tm_sigcontexts() is not
> called, thus, not executing recheckpoint, keeping the CPU state as not
> transactional. When calling rfid, SRR1 will have MSR[TS] set, but the CPU
> state is non transactional, causing the TM Bad Thing with the following
> stack:
> 

Works for me on Linux 4.4 and 4.12

Tested-by: Michal Suchánek <msuchanek@suse.de>

Thanks

  reply	other threads:[~2018-12-07 13:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-26 20:11 [PATCH 1/4] powerpc/tm: Save MSR to PACA before RFID Breno Leitao
2018-11-26 20:11 ` [PATCH 2/4] powerpc/tm: Print scratch value Breno Leitao
2018-11-26 20:12 ` [PATCH 3/4] powerpc/tm: Unset MSR[TS] if not recheckpointing Breno Leitao
2018-11-26 20:12   ` Breno Leitao
2018-12-07 13:48   ` Michal Suchánek [this message]
2018-12-07 13:48     ` Michal Suchánek
2018-11-26 20:12 ` [PATCH 4/4] selftests/powerpc: Add checks for transactional sigreturn Breno Leitao
2018-12-07 13:45   ` Michal Suchánek
2018-12-23 13:27 ` [1/4] powerpc/tm: Save MSR to PACA before RFID Michael Ellerman

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=20181207144838.4f0382c6@naga.suse.cz \
    --to=msuchanek@suse.de \
    --cc=gromero@linux.vnet.ibm.com \
    --cc=leitao@debian.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mikey@neuling.org \
    --cc=stable@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.