[PATCH] powerpc: signals: Discard transaction state from signal frames
Simon Guo
wei.guo.simon at gmail.com
Sat Aug 20 20:03:08 AEST 2016
Hi Cyril,
On Mon, Aug 22, 2016 at 05:32:06PM +1000, Cyril Bur wrote:
> diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
> index b6aa378..31e4e15 100644
> --- a/arch/powerpc/kernel/signal_32.c
> +++ b/arch/powerpc/kernel/signal_32.c
> @@ -1226,7 +1226,19 @@ long sys_rt_sigreturn(int r3, int r4, int r5, int r6, int r7, int r8,
> (regs->gpr[1] + __SIGNAL_FRAMESIZE + 16);
> if (!access_ok(VERIFY_READ, rt_sf, sizeof(*rt_sf)))
> goto bad;
> +
> #ifdef CONFIG_PPC_TRANSACTIONAL_MEM
> + /*
> + * If there is a transactional/suspended state then throw it away.
> + * The purpose of a sigreturn is to destroy all traces of the
> + * signal frame, this includes any transactional state created
> + * within in.
> + * The cause is not important as there will never be a
> + * recheckpoint so it's not user visible.
> + */
> + if (MSR_TM_ACTIVE(mfmsr()))
> + tm_reclaim_current(0);
> +
Maybe a little picky here:
Per my understanding, the TRANSACTIONAL state will be failed in system
call common entry. The only expected state to prevent here is SUSPEND
state.
Should we use MSR_TM_SUSPENDED(mfmsr()) here and BUG_ON
MSR_TM_TRANSACTIONAL(mfmsr())? -- If it is transactional state, something
is wrong with kernel.
Others looks good to me.
Thanks,
- Simon
More information about the Linuxppc-dev
mailing list