| Message ID | 20171102030906.3061-1-cyrilbur@gmail.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | a7771176b4392fbc3a17399c51a8c11f2f681afe |
| Headers | show |
| Series | [v3,1/4] powerpc: Don't enable FP/Altivec if not checkpointed | expand |
On Thu, 2017-11-02 at 03:09:03 UTC, Cyril Bur wrote: > Lazy save and restore of FP/Altivec means that a userspace process can > be sent to userspace with FP or Altivec disabled and loaded only as > required (by way of an FP/Altivec unavailable exception). Transactional > Memory complicates this situation as a transaction could be started > without FP/Altivec being loaded up. This causes the hardware to > checkpoint incorrect registers. Handling FP/Altivec unavailable > exceptions while a thread is transactional requires a reclaim and > recheckpoint to ensure the CPU has correct state for both sets of > registers. > > Lazy save and restore of FP/Altivec cannot be done if a process is > transactional. If a facility was enabled it must remain enabled whenever > a thread is transactional. > > Commit dc16b553c949 ("powerpc: Always restore FPU/VEC/VSX if hardware > transactional memory in use") ensures that the facilities are always > enabled if a thread is transactional. A bug in the introduced code may > cause it to inadvertently enable a facility that was (and should remain) > disabled. The problem with this extraneous enablement is that the > registers for the erroneously enabled facility have not been correctly > recheckpointed - the recheckpointing code assumed the facility would > remain disabled. > > Further compounding the issue, the transactional {fp,altivec,vsx} > unavailable code has been incorrectly using the MSR to enable > facilities. The presence of the {FP,VEC,VSX} bit in the regs->msr simply > means if the registers are live on the CPU, not if the kernel should > load them before returning to userspace. This has worked due to the bug > mentioned above. > > This causes transactional threads which return to their failure handler > to observe incorrect checkpointed registers. Perhaps an example will > help illustrate the problem: > > A userspace process is running and uses both FP and Altivec registers. > This process then continues to run for some time without touching > either sets of registers. The kernel subsequently disables the > facilities as part of lazy save and restore. The userspace process then > performs a tbegin and the CPU checkpoints 'junk' FP and Altivec > registers. The process then performs a floating point instruction > triggering a fp unavailable exception in the kernel. > > The kernel then loads the FP registers - and only the FP registers. > Since the thread is transactional it must perform a reclaim and > recheckpoint to ensure both the checkpointed registers and the > transactional registers are correct. It then (correctly) enables > MSR[FP] for the process. Later (on exception exist) the kernel also > (inadvertently) enables MSR[VEC]. The process is then returned to > userspace. > > Since the act of loading the FP registers doomed the transaction we know > CPU will fail the transaction, restore its checkpointed registers, and > return the process to its failure handler. The problem is that we're > now running with Altivec enabled and the 'junk' checkpointed registers > are restored. The kernel had only recheckpointed FP. > > This patch solves this by only activating FP/Altivec if userspace was > using them when it entered the kernel and not simply if the process is > transactional. > > Fixes: dc16b553c949 ("powerpc: Always restore FPU/VEC/VSX if hardware > transactional memory in use") > > Signed-off-by: Cyril Bur <cyrilbur@gmail.com> Series applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/a7771176b4392fbc3a17399c51a8c1 cheers
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c index a0c74bbf3454..cff887e67eb9 100644 --- a/arch/powerpc/kernel/process.c +++ b/arch/powerpc/kernel/process.c @@ -97,9 +97,23 @@ static inline bool msr_tm_active(unsigned long msr) { return MSR_TM_ACTIVE(msr); } + +static bool tm_active_with_fp(struct task_struct *tsk) +{ + return msr_tm_active(tsk->thread.regs->msr) && + (tsk->thread.ckpt_regs.msr & MSR_FP); +} + +static bool tm_active_with_altivec(struct task_struct *tsk) +{ + return msr_tm_active(tsk->thread.regs->msr) && + (tsk->thread.ckpt_regs.msr & MSR_VEC); +} #else static inline bool msr_tm_active(unsigned long msr) { return false; } static inline void check_if_tm_restore_required(struct task_struct *tsk) { } +static inline bool tm_active_with_fp(struct task_struct *tsk) { return false; } +static inline bool tm_active_with_altivec(struct task_struct *tsk) { return false; } #endif /* CONFIG_PPC_TRANSACTIONAL_MEM */ bool strict_msr_control; @@ -232,7 +246,7 @@ EXPORT_SYMBOL(enable_kernel_fp); static int restore_fp(struct task_struct *tsk) { - if (tsk->thread.load_fp || msr_tm_active(tsk->thread.regs->msr)) { + if (tsk->thread.load_fp || tm_active_with_fp(tsk)) { load_fp_state(¤t->thread.fp_state); current->thread.load_fp++; return 1; @@ -314,7 +328,7 @@ EXPORT_SYMBOL_GPL(flush_altivec_to_thread); static int restore_altivec(struct task_struct *tsk) { if (cpu_has_feature(CPU_FTR_ALTIVEC) && - (tsk->thread.load_vec || msr_tm_active(tsk->thread.regs->msr))) { + (tsk->thread.load_vec || tm_active_with_altivec(tsk))) { load_vr_state(&tsk->thread.vr_state); tsk->thread.used_vr = 1; tsk->thread.load_vec++; diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c index 13c9dcdcba69..ef6a45969812 100644 --- a/arch/powerpc/kernel/traps.c +++ b/arch/powerpc/kernel/traps.c @@ -1487,7 +1487,7 @@ void fp_unavailable_tm(struct pt_regs *regs) /* Reclaim didn't save out any FPRs to transact_fprs. */ /* Enable FP for the task: */ - regs->msr |= (MSR_FP | current->thread.fpexc_mode); + current->thread.load_fp = 1; /* This loads and recheckpoints the FP registers from * thread.fpr[]. They will remain in registers after the @@ -1516,7 +1516,7 @@ void altivec_unavailable_tm(struct pt_regs *regs) "MSR=%lx\n", regs->nip, regs->msr); tm_reclaim_current(TM_CAUSE_FAC_UNAV); - regs->msr |= MSR_VEC; + current->thread.load_vec = 1; tm_recheckpoint(¤t->thread, MSR_VEC); current->thread.used_vr = 1; @@ -1553,8 +1553,8 @@ void vsx_unavailable_tm(struct pt_regs *regs) /* This reclaims FP and/or VR regs if they're already enabled */ tm_reclaim_current(TM_CAUSE_FAC_UNAV); - regs->msr |= MSR_VEC | MSR_FP | current->thread.fpexc_mode | - MSR_VSX; + current->thread.load_vec = 1; + current->thread.load_fp = 1; /* This loads & recheckpoints FP and VRs; but we have * to be sure not to overwrite previously-valid state.
Lazy save and restore of FP/Altivec means that a userspace process can be sent to userspace with FP or Altivec disabled and loaded only as required (by way of an FP/Altivec unavailable exception). Transactional Memory complicates this situation as a transaction could be started without FP/Altivec being loaded up. This causes the hardware to checkpoint incorrect registers. Handling FP/Altivec unavailable exceptions while a thread is transactional requires a reclaim and recheckpoint to ensure the CPU has correct state for both sets of registers. Lazy save and restore of FP/Altivec cannot be done if a process is transactional. If a facility was enabled it must remain enabled whenever a thread is transactional. Commit dc16b553c949 ("powerpc: Always restore FPU/VEC/VSX if hardware transactional memory in use") ensures that the facilities are always enabled if a thread is transactional. A bug in the introduced code may cause it to inadvertently enable a facility that was (and should remain) disabled. The problem with this extraneous enablement is that the registers for the erroneously enabled facility have not been correctly recheckpointed - the recheckpointing code assumed the facility would remain disabled. Further compounding the issue, the transactional {fp,altivec,vsx} unavailable code has been incorrectly using the MSR to enable facilities. The presence of the {FP,VEC,VSX} bit in the regs->msr simply means if the registers are live on the CPU, not if the kernel should load them before returning to userspace. This has worked due to the bug mentioned above. This causes transactional threads which return to their failure handler to observe incorrect checkpointed registers. Perhaps an example will help illustrate the problem: A userspace process is running and uses both FP and Altivec registers. This process then continues to run for some time without touching either sets of registers. The kernel subsequently disables the facilities as part of lazy save and restore. The userspace process then performs a tbegin and the CPU checkpoints 'junk' FP and Altivec registers. The process then performs a floating point instruction triggering a fp unavailable exception in the kernel. The kernel then loads the FP registers - and only the FP registers. Since the thread is transactional it must perform a reclaim and recheckpoint to ensure both the checkpointed registers and the transactional registers are correct. It then (correctly) enables MSR[FP] for the process. Later (on exception exist) the kernel also (inadvertently) enables MSR[VEC]. The process is then returned to userspace. Since the act of loading the FP registers doomed the transaction we know CPU will fail the transaction, restore its checkpointed registers, and return the process to its failure handler. The problem is that we're now running with Altivec enabled and the 'junk' checkpointed registers are restored. The kernel had only recheckpointed FP. This patch solves this by only activating FP/Altivec if userspace was using them when it entered the kernel and not simply if the process is transactional. Fixes: dc16b553c949 ("powerpc: Always restore FPU/VEC/VSX if hardware transactional memory in use") Signed-off-by: Cyril Bur <cyrilbur@gmail.com> --- V2: Rather than incorrectly using the MSR to enable {FP,VEC,VSX} use the load_fp and load_vec booleans to help restore_math() make the correct decision V3: Put tm_active_with_{fp,altivec}() inside a #ifdef CONFIG_PPC_TRANSACTIONAL_MEM arch/powerpc/kernel/process.c | 18 ++++++++++++++++-- arch/powerpc/kernel/traps.c | 8 ++++---- 2 files changed, 20 insertions(+), 6 deletions(-)