[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