[PATCH Yakkety SRU] powerpc/process: Fix CONFIG_ALIVEC typo in restore_tm_state()
Tim Gardner
tim.gardner at canonical.com
Wed Mar 1 20:17:34 UTC 2017
From: Valentin Rothberg <valentinrothberg at gmail.com>
BugLink: http://bugs.launchpad.net/bugs/1669023
It should be ALTIVEC, not ALIVEC.
Cyril explains: If a thread performs a transaction with altivec and then
gets preempted for whatever reason, this bug may cause the kernel to not
re-enable altivec when that thread runs again. This will result in an
altivec unavailable fault, when that fault happens inside a user
transaction the kernel has no choice but to enable altivec and doom the
transaction.
The result is that transactions using altivec may get aborted more often
than they should.
The difficulty in catching this with a selftest is my deliberate use of
the word may above. Optimisations to avoid FPU/altivec/VSX faults mean
that the kernel will always leave them on for 255 switches. This code
prevents the kernel turning it off if it got to the 256th switch (and
userspace was transactional).
Fixes: dc16b553c949 ("powerpc: Always restore FPU/VEC/VSX if hardware transactional memory in use")
Reviewed-by: Cyril Bur <cyrilbur at gmail.com>
Signed-off-by: Valentin Rothberg <valentinrothberg at gmail.com>
Signed-off-by: Michael Ellerman <mpe at ellerman.id.au>
(cherry picked from commit 39715bf972ed4fee18fe5409609a971fb16b1771)
Signed-off-by: Tim Gardner <tim.gardner at canonical.com>
---
arch/powerpc/kernel/process.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index bb5ed9e..b7ba944 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -995,7 +995,7 @@ void restore_tm_state(struct pt_regs *regs)
/* Ensure that restore_math() will restore */
if (msr_diff & MSR_FP)
current->thread.load_fp = 1;
-#ifdef CONFIG_ALIVEC
+#ifdef CONFIG_ALTIVEC
if (cpu_has_feature(CPU_FTR_ALTIVEC) && msr_diff & MSR_VEC)
current->thread.load_vec = 1;
#endif
--
2.7.4
More information about the kernel-team
mailing list