Patch "powerpc: Always restore FPU/VEC/VSX if hardware transactional memory in use" has been added to the 4.8-stable tree
Subsystems (2)
This is a note to let you know that I've just added the patch titled
powerpc: Always restore FPU/VEC/VSX if hardware transactional memory in use
to the 4.8-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-always-restore-fpu-vec-vsx-if-hardware-transactional-memory-in-use.patch
and it can be found in the queue-4.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.
Quoted 1 line
From
dc16b553c949e81f37555777dc7bab66d78285a7Mon Sep 17 00:00:00 2001
From: Cyril Bur <[email protected]>
Date: Fri, 23 Sep 2016 16:18:08 +1000
Subject: powerpc: Always restore FPU/VEC/VSX if hardware transactional memory in use
From: Cyril Bur <[email protected]>
commit dc16b553c949e81f37555777dc7bab66d78285a7 upstream.
Comment from arch/powerpc/kernel/process.c:967:
If userspace is inside a transaction (whether active or suspended) and FP/VMX/VSX instructions have ever been enabled inside that transaction, then we have to keep them enabled and keep the FP/VMX/VSX state loaded while ever the transaction continues. The reason is that if we didn't, and subsequently got a FP/VMX/VSX unavailable interrupt inside a transaction, we don't know whether it's the same transaction, and thus we don't know which of the checkpointed state and the ransactional state to use.
restore_math() restore_fp() and restore_altivec() currently may not restore the registers. It doesn't appear that this is more serious than a performance penalty. If the math registers aren't restored the userspace thread will still be run with the facility disabled. Userspace will not be able to read invalid values. On the first access it will take an facility unavailable exception and the kernel will detected an active transaction, at which point it will abort the transaction. There is the possibility for a pathological case preventing any progress by transactions, however, transactions are never guaranteed to make progress.
--- arch/powerpc/kernel/process.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-)
arch/powerpc/kernel/process.c +18 -3
@@ -88,7 +88,13 @@ static void check_if_tm_restore_required set_thread_flag(TIF_RESTORE_TM); } } + +static inline bool msr_tm_active (unsigned long msr) +{ +return MSR_TM_ACTIVE (msr); +}#else +static inline bool msr_tm_active (unsigned long msr) {return false; }static inline void check_if_tm_restore_required (struct task_struct *tsk) { }#endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
@@ -208,7 +214,7 @@ void enable_kernel_fp(void)EXPORT_SYMBOL (enable_kernel_fp);static int restore_fp (struct task_struct *tsk) { -if (tsk->thread.load_fp) { +if (tsk->thread.load_fp ||msr_tm_active (tsk->thread.regs->msr)) {load_fp_state (¤t->thread.fp_state); current->thread.load_fp++;return 1 ;
@@ -278,7 +284,8 @@ EXPORT_SYMBOL_GPL(flush_altivec_to_threastatic int restore_altivec (struct task_struct *tsk) { -if (cpu_has_feature (CPU_FTR_ALTIVEC ) && tsk->thread.load_vec) { +if (cpu_has_feature (CPU_FTR_ALTIVEC ) && + (tsk->thread.load_vec ||msr_tm_active (tsk->thread.regs->msr))) {load_vr_state (&tsk->thread.vr_state); tsk->thread.used_vr =1 ; tsk->thread.load_vec++;
@@ -464,7 +471,8 @@ void restore_math(struct pt_regs *regs) {unsigned long msr; -if (!current->thread.load_fp && !loadvec (current->thread)) +if (!msr_tm_active (regs->msr) && + !current->thread.load_fp && !loadvec (current->thread))return ; msr = regs->msr;
@@ -983,6 +991,13 @@ void restore_tm_state(struct pt_regs *re msr_diff = current->thread.ckpt_regs.msr & ~regs->msr; msr_diff &=MSR_FP |MSR_VEC |MSR_VSX ; +/* Ensure that restore_math() will restore */ +if (msr_diff &MSR_FP ) + current->thread.load_fp =1 ; +#ifdef CONFIG_ALIVEC +if (cpu_has_feature (CPU_FTR_ALTIVEC ) && msr_diff &MSR_VEC ) + current->thread.load_vec =1 ; +#endif restore_math (regs); regs->msr |= msr_diff;
Patches currently in stable-queue which might be from [email protected] are
queue-4.8/powerpc-add-check_if_tm_restore_required-to-giveup_all.patch queue-4.8/powerpc-always-restore-fpu-vec-vsx-if-hardware-transactional-memory-in-use.patch