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
