This is a note to let you know that I've just added the patch titled

    powerpc/tm: Fix return of active 64bit signals

to the 3.10-stable tree which can be found at:
    
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     powerpc-tm-fix-return-of-active-64bit-signals.patch
and it can be found in the queue-3.10 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.


>From 87b4e5393af77f5cba124638f19f6c426e210aec Mon Sep 17 00:00:00 2001
From: Michael Neuling <[email protected]>
Date: Sun, 9 Jun 2013 21:23:19 +1000
Subject: powerpc/tm: Fix return of active 64bit signals

From: Michael Neuling <[email protected]>

commit 87b4e5393af77f5cba124638f19f6c426e210aec upstream.

Currently we only restore signals which are transactionally suspended but it's
possible that the transaction can be restored even when it's active.  Most
likely this will result in a transactional rollback by the hardware as the
transaction will have been doomed by an earlier treclaim.

The current code is a legacy of earlier kernel implementations which did
software rollback of active transactions in the kernel.  That code has now gone
but we didn't correctly fix up this part of the signals code which still makes
assumptions based on having software rollback.

This changes the signal return code to always restore both contexts on 64 bit
signal return.  It also ensures that the MSR TM bits are properly restored from
the signal context which they are not currently.

Signed-off-by: Michael Neuling <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/kernel/signal_64.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

--- a/arch/powerpc/kernel/signal_64.c
+++ b/arch/powerpc/kernel/signal_64.c
@@ -410,6 +410,10 @@ static long restore_tm_sigcontexts(struc
 
        /* get MSR separately, transfer the LE bit if doing signal return */
        err |= __get_user(msr, &sc->gp_regs[PT_MSR]);
+       /* pull in MSR TM from user context */
+       regs->msr = (regs->msr & ~MSR_TS_MASK) | (msr & MSR_TS_MASK);
+
+       /* pull in MSR LE from user context */
        regs->msr = (regs->msr & ~MSR_LE) | (msr & MSR_LE);
 
        /* The following non-GPR non-FPR non-VR state is also checkpointed: */
@@ -505,8 +509,6 @@ static long restore_tm_sigcontexts(struc
        tm_enable();
        /* This loads the checkpointed FP/VEC state, if used */
        tm_recheckpoint(&current->thread, msr);
-       /* The task has moved into TM state S, so ensure MSR reflects this: */
-       regs->msr = (regs->msr & ~MSR_TS_MASK) | __MASK(33);
 
        /* This loads the speculative FP/VEC state, if used */
        if (msr & MSR_FP) {
@@ -654,7 +656,7 @@ int sys_rt_sigreturn(unsigned long r3, u
 #ifdef CONFIG_PPC_TRANSACTIONAL_MEM
        if (__get_user(msr, &uc->uc_mcontext.gp_regs[PT_MSR]))
                goto badframe;
-       if (MSR_TM_SUSPENDED(msr)) {
+       if (MSR_TM_ACTIVE(msr)) {
                /* We recheckpoint on return. */
                struct ucontext __user *uc_transact;
                if (__get_user(uc_transact, &uc->uc_link))


Patches currently in stable-queue which might be from [email protected] are

queue-3.10/powerpc-tm-fix-writing-top-half-of-msr-on-32-bit-signals.patch
queue-3.10/powerpc-tm-fix-return-of-active-64bit-signals.patch
queue-3.10/powerpc-tm-fix-return-of-32bit-rt-signals-to-active-transactions.patch
queue-3.10/powerpc-tm-fix-restoration-of-msr-on-32bit-signal-return.patch
queue-3.10/powerpc-hw_brk-fix-clearing-of-extraneous-irq.patch
queue-3.10/powerpc-hw_brk-fix-off-by-one-error-when-validating-dawr-region-end.patch
queue-3.10/powerpc-hw_brk-fix-setting-of-length-for-exact-mode-breakpoints.patch
queue-3.10/powerpc-tm-fix-32-bit-non-rt-signals.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to