2019-05-27 08:55:01 +02:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later */
|
2005-09-26 16:04:21 +10:00
|
|
|
/*
|
|
|
|
|
* FPU support code, moved here from head.S so that it can be used
|
|
|
|
|
* by chips which use other head-whatever.S files.
|
|
|
|
|
*
|
2006-08-30 14:45:35 +10:00
|
|
|
* Copyright (C) 1995-1996 Gary Thomas (gdt@linuxppc.org)
|
|
|
|
|
* Copyright (C) 1996 Cort Dougan <cort@cs.nmt.edu>
|
|
|
|
|
* Copyright (C) 1996 Paul Mackerras.
|
|
|
|
|
* Copyright (C) 1997 Dan Malek (dmalek@jlc.net).
|
2005-09-26 16:04:21 +10:00
|
|
|
*/
|
|
|
|
|
|
2023-08-07 00:09:53 +09:00
|
|
|
#include <linux/export.h>
|
2005-10-10 22:20:10 +10:00
|
|
|
#include <asm/reg.h>
|
2005-09-26 16:04:21 +10:00
|
|
|
#include <asm/page.h>
|
|
|
|
|
#include <asm/mmu.h>
|
|
|
|
|
#include <asm/cputable.h>
|
|
|
|
|
#include <asm/cache.h>
|
|
|
|
|
#include <asm/thread_info.h>
|
|
|
|
|
#include <asm/ppc_asm.h>
|
|
|
|
|
#include <asm/asm-offsets.h>
|
2010-11-18 15:06:17 +00:00
|
|
|
#include <asm/ptrace.h>
|
2018-07-05 16:24:57 +00:00
|
|
|
#include <asm/asm-compat.h>
|
2018-07-05 16:25:01 +00:00
|
|
|
#include <asm/feature-fixups.h>
|
2005-09-26 16:04:21 +10:00
|
|
|
|
2008-06-25 14:07:18 +10:00
|
|
|
#ifdef CONFIG_VSX
|
powerpc: Don't clobber f0/vs0 during fp|altivec register save
During floating point and vector save to thread data f0/vs0 are
clobbered by the FPSCR/VSCR store routine. This has been obvserved to
lead to userspace register corruption and application data corruption
with io-uring.
Fix it by restoring f0/vs0 after FPSCR/VSCR store has completed for
all the FP, altivec, VMX register save paths.
Tested under QEMU in kvm mode, running on a Talos II workstation with
dual POWER9 DD2.2 CPUs.
Additional detail (mpe):
Typically save_fpu() is called from __giveup_fpu() which saves the FP
regs and also *turns off FP* in the tasks MSR, meaning the kernel will
reload the FP regs from the thread struct before letting the task use FP
again. So in that case save_fpu() is free to clobber f0 because the FP
regs no longer hold live values for the task.
There is another case though, which is the path via:
sys_clone()
...
copy_process()
dup_task_struct()
arch_dup_task_struct()
flush_all_to_thread()
save_all()
That path saves the FP regs but leaves them live. That's meant as an
optimisation for a process that's using FP/VSX and then calls fork(),
leaving the regs live means the parent process doesn't have to take a
fault after the fork to get its FP regs back. The optimisation was added
in commit 8792468da5e1 ("powerpc: Add the ability to save FPU without
giving it up").
That path does clobber f0, but f0 is volatile across function calls,
and typically programs reach copy_process() from userspace via a syscall
wrapper function. So in normal usage f0 being clobbered across a
syscall doesn't cause visible data corruption.
But there is now a new path, because io-uring can call copy_process()
via create_io_thread() from the signal handling path. That's OK if the
signal is handled as part of syscall return, but it's not OK if the
signal is handled due to some other interrupt.
That path is:
interrupt_return_srr_user()
interrupt_exit_user_prepare()
interrupt_exit_user_prepare_main()
do_notify_resume()
get_signal()
task_work_run()
create_worker_cb()
create_io_worker()
copy_process()
dup_task_struct()
arch_dup_task_struct()
flush_all_to_thread()
save_all()
if (tsk->thread.regs->msr & MSR_FP)
save_fpu()
# f0 is clobbered and potentially live in userspace
Note the above discussion applies equally to save_altivec().
Fixes: 8792468da5e1 ("powerpc: Add the ability to save FPU without giving it up")
Cc: stable@vger.kernel.org # v4.6+
Closes: https://lore.kernel.org/all/480932026.45576726.1699374859845.JavaMail.zimbra@raptorengineeringinc.com/
Closes: https://lore.kernel.org/linuxppc-dev/480221078.47953493.1700206777956.JavaMail.zimbra@raptorengineeringinc.com/
Tested-by: Timothy Pearson <tpearson@raptorengineering.com>
Tested-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
[mpe: Reword change log to describe exact path of corruption & other minor tweaks]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/1921539696.48534988.1700407082933.JavaMail.zimbra@raptorengineeringinc.com
2023-11-19 09:18:02 -06:00
|
|
|
#define __REST_1FPVSR(n,c,base) \
|
|
|
|
|
BEGIN_FTR_SECTION \
|
|
|
|
|
b 2f; \
|
|
|
|
|
END_FTR_SECTION_IFSET(CPU_FTR_VSX); \
|
|
|
|
|
REST_FPR(n,base); \
|
|
|
|
|
b 3f; \
|
|
|
|
|
2: REST_VSR(n,c,base); \
|
|
|
|
|
3:
|
|
|
|
|
|
2012-06-25 13:33:23 +00:00
|
|
|
#define __REST_32FPVSRS(n,c,base) \
|
2008-06-25 14:07:18 +10:00
|
|
|
BEGIN_FTR_SECTION \
|
|
|
|
|
b 2f; \
|
|
|
|
|
END_FTR_SECTION_IFSET(CPU_FTR_VSX); \
|
|
|
|
|
REST_32FPRS(n,base); \
|
|
|
|
|
b 3f; \
|
|
|
|
|
2: REST_32VSRS(n,c,base); \
|
|
|
|
|
3:
|
|
|
|
|
|
2012-06-25 13:33:23 +00:00
|
|
|
#define __SAVE_32FPVSRS(n,c,base) \
|
2008-06-25 14:07:18 +10:00
|
|
|
BEGIN_FTR_SECTION \
|
|
|
|
|
b 2f; \
|
|
|
|
|
END_FTR_SECTION_IFSET(CPU_FTR_VSX); \
|
|
|
|
|
SAVE_32FPRS(n,base); \
|
|
|
|
|
b 3f; \
|
|
|
|
|
2: SAVE_32VSRS(n,c,base); \
|
|
|
|
|
3:
|
|
|
|
|
#else
|
powerpc: Don't clobber f0/vs0 during fp|altivec register save
During floating point and vector save to thread data f0/vs0 are
clobbered by the FPSCR/VSCR store routine. This has been obvserved to
lead to userspace register corruption and application data corruption
with io-uring.
Fix it by restoring f0/vs0 after FPSCR/VSCR store has completed for
all the FP, altivec, VMX register save paths.
Tested under QEMU in kvm mode, running on a Talos II workstation with
dual POWER9 DD2.2 CPUs.
Additional detail (mpe):
Typically save_fpu() is called from __giveup_fpu() which saves the FP
regs and also *turns off FP* in the tasks MSR, meaning the kernel will
reload the FP regs from the thread struct before letting the task use FP
again. So in that case save_fpu() is free to clobber f0 because the FP
regs no longer hold live values for the task.
There is another case though, which is the path via:
sys_clone()
...
copy_process()
dup_task_struct()
arch_dup_task_struct()
flush_all_to_thread()
save_all()
That path saves the FP regs but leaves them live. That's meant as an
optimisation for a process that's using FP/VSX and then calls fork(),
leaving the regs live means the parent process doesn't have to take a
fault after the fork to get its FP regs back. The optimisation was added
in commit 8792468da5e1 ("powerpc: Add the ability to save FPU without
giving it up").
That path does clobber f0, but f0 is volatile across function calls,
and typically programs reach copy_process() from userspace via a syscall
wrapper function. So in normal usage f0 being clobbered across a
syscall doesn't cause visible data corruption.
But there is now a new path, because io-uring can call copy_process()
via create_io_thread() from the signal handling path. That's OK if the
signal is handled as part of syscall return, but it's not OK if the
signal is handled due to some other interrupt.
That path is:
interrupt_return_srr_user()
interrupt_exit_user_prepare()
interrupt_exit_user_prepare_main()
do_notify_resume()
get_signal()
task_work_run()
create_worker_cb()
create_io_worker()
copy_process()
dup_task_struct()
arch_dup_task_struct()
flush_all_to_thread()
save_all()
if (tsk->thread.regs->msr & MSR_FP)
save_fpu()
# f0 is clobbered and potentially live in userspace
Note the above discussion applies equally to save_altivec().
Fixes: 8792468da5e1 ("powerpc: Add the ability to save FPU without giving it up")
Cc: stable@vger.kernel.org # v4.6+
Closes: https://lore.kernel.org/all/480932026.45576726.1699374859845.JavaMail.zimbra@raptorengineeringinc.com/
Closes: https://lore.kernel.org/linuxppc-dev/480221078.47953493.1700206777956.JavaMail.zimbra@raptorengineeringinc.com/
Tested-by: Timothy Pearson <tpearson@raptorengineering.com>
Tested-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
[mpe: Reword change log to describe exact path of corruption & other minor tweaks]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/1921539696.48534988.1700407082933.JavaMail.zimbra@raptorengineeringinc.com
2023-11-19 09:18:02 -06:00
|
|
|
#define __REST_1FPVSR(n,b,base) REST_FPR(n, base)
|
2012-06-25 13:33:23 +00:00
|
|
|
#define __REST_32FPVSRS(n,b,base) REST_32FPRS(n, base)
|
|
|
|
|
#define __SAVE_32FPVSRS(n,b,base) SAVE_32FPRS(n, base)
|
2008-06-25 14:07:18 +10:00
|
|
|
#endif
|
powerpc: Don't clobber f0/vs0 during fp|altivec register save
During floating point and vector save to thread data f0/vs0 are
clobbered by the FPSCR/VSCR store routine. This has been obvserved to
lead to userspace register corruption and application data corruption
with io-uring.
Fix it by restoring f0/vs0 after FPSCR/VSCR store has completed for
all the FP, altivec, VMX register save paths.
Tested under QEMU in kvm mode, running on a Talos II workstation with
dual POWER9 DD2.2 CPUs.
Additional detail (mpe):
Typically save_fpu() is called from __giveup_fpu() which saves the FP
regs and also *turns off FP* in the tasks MSR, meaning the kernel will
reload the FP regs from the thread struct before letting the task use FP
again. So in that case save_fpu() is free to clobber f0 because the FP
regs no longer hold live values for the task.
There is another case though, which is the path via:
sys_clone()
...
copy_process()
dup_task_struct()
arch_dup_task_struct()
flush_all_to_thread()
save_all()
That path saves the FP regs but leaves them live. That's meant as an
optimisation for a process that's using FP/VSX and then calls fork(),
leaving the regs live means the parent process doesn't have to take a
fault after the fork to get its FP regs back. The optimisation was added
in commit 8792468da5e1 ("powerpc: Add the ability to save FPU without
giving it up").
That path does clobber f0, but f0 is volatile across function calls,
and typically programs reach copy_process() from userspace via a syscall
wrapper function. So in normal usage f0 being clobbered across a
syscall doesn't cause visible data corruption.
But there is now a new path, because io-uring can call copy_process()
via create_io_thread() from the signal handling path. That's OK if the
signal is handled as part of syscall return, but it's not OK if the
signal is handled due to some other interrupt.
That path is:
interrupt_return_srr_user()
interrupt_exit_user_prepare()
interrupt_exit_user_prepare_main()
do_notify_resume()
get_signal()
task_work_run()
create_worker_cb()
create_io_worker()
copy_process()
dup_task_struct()
arch_dup_task_struct()
flush_all_to_thread()
save_all()
if (tsk->thread.regs->msr & MSR_FP)
save_fpu()
# f0 is clobbered and potentially live in userspace
Note the above discussion applies equally to save_altivec().
Fixes: 8792468da5e1 ("powerpc: Add the ability to save FPU without giving it up")
Cc: stable@vger.kernel.org # v4.6+
Closes: https://lore.kernel.org/all/480932026.45576726.1699374859845.JavaMail.zimbra@raptorengineeringinc.com/
Closes: https://lore.kernel.org/linuxppc-dev/480221078.47953493.1700206777956.JavaMail.zimbra@raptorengineeringinc.com/
Tested-by: Timothy Pearson <tpearson@raptorengineering.com>
Tested-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
[mpe: Reword change log to describe exact path of corruption & other minor tweaks]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/1921539696.48534988.1700407082933.JavaMail.zimbra@raptorengineeringinc.com
2023-11-19 09:18:02 -06:00
|
|
|
#define REST_1FPVSR(n,c,base) __REST_1FPVSR(n,__REG_##c,__REG_##base)
|
2012-06-25 13:33:23 +00:00
|
|
|
#define REST_32FPVSRS(n,c,base) __REST_32FPVSRS(n,__REG_##c,__REG_##base)
|
|
|
|
|
#define SAVE_32FPVSRS(n,c,base) __SAVE_32FPVSRS(n,__REG_##c,__REG_##base)
|
2008-06-25 14:07:18 +10:00
|
|
|
|
2013-09-10 20:21:10 +10:00
|
|
|
/*
|
|
|
|
|
* Load state from memory into FP registers including FPSCR.
|
|
|
|
|
* Assumes the caller has enabled FP in the MSR.
|
|
|
|
|
*/
|
|
|
|
|
_GLOBAL(load_fp_state)
|
|
|
|
|
lfd fr0,FPSTATE_FPSCR(r3)
|
|
|
|
|
MTFSF_L(fr0)
|
|
|
|
|
REST_32FPVSRS(0, R4, R3)
|
|
|
|
|
blr
|
2016-01-13 23:33:46 -05:00
|
|
|
EXPORT_SYMBOL(load_fp_state)
|
powerpc/64: Don't trace code that runs with the soft irq mask unreconciled
"Reconciling" in terms of interrupt handling, is to bring the soft irq
mask state in to synch with the hardware, after an interrupt causes
MSR[EE] to be cleared (while the soft mask may be enabled, and hard
irqs not marked disabled).
General kernel code should not be called while unreconciled, because
local_irq_disable, etc. manipulations can cause surprising irq traces,
and it's fragile because the soft irq code does not really expect to
be called in this situation.
When exiting from an interrupt, MSR[EE] is cleared to prevent races,
but soft irq state is enabled for the returned-to context, so this is
now an unreconciled state. restore_math is called in this state, and
that can be ftraced, and the ftrace subsystem disables local irqs.
Mark restore_math and its callees as notrace. Restore a sanity check
in the soft irq code that had to be disabled for this case, by commit
4da1f79227ad4 ("powerpc/64: Disable irq restore warning for now").
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-05-02 15:21:07 +10:00
|
|
|
_ASM_NOKPROBE_SYMBOL(load_fp_state); /* used by restore_math */
|
2013-09-10 20:21:10 +10:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Store FP state into memory, including FPSCR
|
|
|
|
|
* Assumes the caller has enabled FP in the MSR.
|
|
|
|
|
*/
|
|
|
|
|
_GLOBAL(store_fp_state)
|
|
|
|
|
SAVE_32FPVSRS(0, R4, R3)
|
|
|
|
|
mffs fr0
|
|
|
|
|
stfd fr0,FPSTATE_FPSCR(r3)
|
powerpc: Don't clobber f0/vs0 during fp|altivec register save
During floating point and vector save to thread data f0/vs0 are
clobbered by the FPSCR/VSCR store routine. This has been obvserved to
lead to userspace register corruption and application data corruption
with io-uring.
Fix it by restoring f0/vs0 after FPSCR/VSCR store has completed for
all the FP, altivec, VMX register save paths.
Tested under QEMU in kvm mode, running on a Talos II workstation with
dual POWER9 DD2.2 CPUs.
Additional detail (mpe):
Typically save_fpu() is called from __giveup_fpu() which saves the FP
regs and also *turns off FP* in the tasks MSR, meaning the kernel will
reload the FP regs from the thread struct before letting the task use FP
again. So in that case save_fpu() is free to clobber f0 because the FP
regs no longer hold live values for the task.
There is another case though, which is the path via:
sys_clone()
...
copy_process()
dup_task_struct()
arch_dup_task_struct()
flush_all_to_thread()
save_all()
That path saves the FP regs but leaves them live. That's meant as an
optimisation for a process that's using FP/VSX and then calls fork(),
leaving the regs live means the parent process doesn't have to take a
fault after the fork to get its FP regs back. The optimisation was added
in commit 8792468da5e1 ("powerpc: Add the ability to save FPU without
giving it up").
That path does clobber f0, but f0 is volatile across function calls,
and typically programs reach copy_process() from userspace via a syscall
wrapper function. So in normal usage f0 being clobbered across a
syscall doesn't cause visible data corruption.
But there is now a new path, because io-uring can call copy_process()
via create_io_thread() from the signal handling path. That's OK if the
signal is handled as part of syscall return, but it's not OK if the
signal is handled due to some other interrupt.
That path is:
interrupt_return_srr_user()
interrupt_exit_user_prepare()
interrupt_exit_user_prepare_main()
do_notify_resume()
get_signal()
task_work_run()
create_worker_cb()
create_io_worker()
copy_process()
dup_task_struct()
arch_dup_task_struct()
flush_all_to_thread()
save_all()
if (tsk->thread.regs->msr & MSR_FP)
save_fpu()
# f0 is clobbered and potentially live in userspace
Note the above discussion applies equally to save_altivec().
Fixes: 8792468da5e1 ("powerpc: Add the ability to save FPU without giving it up")
Cc: stable@vger.kernel.org # v4.6+
Closes: https://lore.kernel.org/all/480932026.45576726.1699374859845.JavaMail.zimbra@raptorengineeringinc.com/
Closes: https://lore.kernel.org/linuxppc-dev/480221078.47953493.1700206777956.JavaMail.zimbra@raptorengineeringinc.com/
Tested-by: Timothy Pearson <tpearson@raptorengineering.com>
Tested-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
[mpe: Reword change log to describe exact path of corruption & other minor tweaks]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/1921539696.48534988.1700407082933.JavaMail.zimbra@raptorengineeringinc.com
2023-11-19 09:18:02 -06:00
|
|
|
REST_1FPVSR(0, R4, R3)
|
2013-09-10 20:21:10 +10:00
|
|
|
blr
|
2016-01-13 23:33:46 -05:00
|
|
|
EXPORT_SYMBOL(store_fp_state)
|
2013-09-10 20:21:10 +10:00
|
|
|
|
2005-09-26 16:04:21 +10:00
|
|
|
/*
|
|
|
|
|
* This task wants to use the FPU now.
|
|
|
|
|
* On UP, disable FP for the task which had the FPU previously,
|
|
|
|
|
* and save its floating-point registers in its thread_struct.
|
|
|
|
|
* Load up this task's FP registers from its thread_struct,
|
|
|
|
|
* enable the FPU for the current task and return to the task.
|
2013-10-23 09:40:02 +01:00
|
|
|
* Note that on 32-bit this can only use registers that will be
|
|
|
|
|
* restored by fast_exception_return, i.e. r3 - r6, r10 and r11.
|
2005-09-26 16:04:21 +10:00
|
|
|
*/
|
2005-10-06 10:59:19 +10:00
|
|
|
_GLOBAL(load_up_fpu)
|
2005-09-26 16:04:21 +10:00
|
|
|
mfmsr r5
|
powerpc/64s/interrupt: handle MSR EE and RI in interrupt entry wrapper
The mtmsrd to enable MSR[RI] can be combined with the mtmsrd to enable
MSR[EE] in interrupt entry code, for those interrupts which enable EE.
This helps performance of important synchronous interrupts (e.g., page
faults).
This is similar to what commit dd152f70bdc1 ("powerpc/64s: system call
avoid setting MSR[RI] until we set MSR[EE]") does for system calls.
Do this by enabling EE and RI together at the beginning of the entry
wrapper if PACA_IRQ_HARD_DIS is clear, and only enabling RI if it is
set.
Asynchronous interrupts set PACA_IRQ_HARD_DIS, but synchronous ones
leave it unchanged, so by default they always get EE=1 unless they have
interrupted a caller that is hard disabled. When the sync interrupt
later calls interrupt_cond_local_irq_enable(), it will not require
another mtmsrd because MSR[EE] was already enabled here.
This avoids one mtmsrd L=1 for synchronous interrupts on 64s, which
saves about 20 cycles on POWER9. And for kernel-mode interrupts, both
synchronous and asynchronous, this saves an additional 40 cycles due to
the mtmsrd being moved ahead of mfspr SPRN_AMR, which prevents a SPR
scoreboard stall.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210922145452.352571-3-npiggin@gmail.com
2021-09-23 00:54:48 +10:00
|
|
|
#ifdef CONFIG_PPC_BOOK3S_64
|
|
|
|
|
/* interrupt doesn't set MSR[RI] and HPT can fault on current access */
|
|
|
|
|
ori r5,r5,MSR_FP|MSR_RI
|
|
|
|
|
#else
|
2005-09-26 16:04:21 +10:00
|
|
|
ori r5,r5,MSR_FP
|
powerpc/64s/interrupt: handle MSR EE and RI in interrupt entry wrapper
The mtmsrd to enable MSR[RI] can be combined with the mtmsrd to enable
MSR[EE] in interrupt entry code, for those interrupts which enable EE.
This helps performance of important synchronous interrupts (e.g., page
faults).
This is similar to what commit dd152f70bdc1 ("powerpc/64s: system call
avoid setting MSR[RI] until we set MSR[EE]") does for system calls.
Do this by enabling EE and RI together at the beginning of the entry
wrapper if PACA_IRQ_HARD_DIS is clear, and only enabling RI if it is
set.
Asynchronous interrupts set PACA_IRQ_HARD_DIS, but synchronous ones
leave it unchanged, so by default they always get EE=1 unless they have
interrupted a caller that is hard disabled. When the sync interrupt
later calls interrupt_cond_local_irq_enable(), it will not require
another mtmsrd because MSR[EE] was already enabled here.
This avoids one mtmsrd L=1 for synchronous interrupts on 64s, which
saves about 20 cycles on POWER9. And for kernel-mode interrupts, both
synchronous and asynchronous, this saves an additional 40 cycles due to
the mtmsrd being moved ahead of mfspr SPRN_AMR, which prevents a SPR
scoreboard stall.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210922145452.352571-3-npiggin@gmail.com
2021-09-23 00:54:48 +10:00
|
|
|
#endif
|
2008-06-25 14:07:18 +10:00
|
|
|
#ifdef CONFIG_VSX
|
|
|
|
|
BEGIN_FTR_SECTION
|
|
|
|
|
oris r5,r5,MSR_VSX@h
|
|
|
|
|
END_FTR_SECTION_IFSET(CPU_FTR_VSX)
|
|
|
|
|
#endif
|
2005-09-26 16:04:21 +10:00
|
|
|
MTMSRD(r5) /* enable use of fpu now */
|
|
|
|
|
isync
|
|
|
|
|
/* enable use of FP after return */
|
2005-10-06 10:59:19 +10:00
|
|
|
#ifdef CONFIG_PPC32
|
2021-08-18 08:47:28 +00:00
|
|
|
addi r5,r2,THREAD
|
2005-09-26 16:04:21 +10:00
|
|
|
lwz r4,THREAD_FPEXC_MODE(r5)
|
|
|
|
|
ori r9,r9,MSR_FP /* enable FP for current */
|
|
|
|
|
or r9,r9,r4
|
2005-10-06 10:59:19 +10:00
|
|
|
#else
|
|
|
|
|
ld r4,PACACURRENT(r13)
|
|
|
|
|
addi r5,r4,THREAD /* Get THREAD */
|
2006-02-07 13:55:30 +11:00
|
|
|
lwz r4,THREAD_FPEXC_MODE(r5)
|
2005-10-06 10:59:19 +10:00
|
|
|
ori r12,r12,MSR_FP
|
|
|
|
|
or r12,r12,r4
|
|
|
|
|
std r12,_MSR(r1)
|
2021-06-18 01:51:03 +10:00
|
|
|
#ifdef CONFIG_PPC_BOOK3S_64
|
|
|
|
|
li r4,0
|
|
|
|
|
stb r4,PACASRR_VALID(r13)
|
|
|
|
|
#endif
|
2005-10-06 10:59:19 +10:00
|
|
|
#endif
|
2020-06-24 09:41:39 +10:00
|
|
|
li r4,1
|
2016-02-29 17:53:47 +11:00
|
|
|
stb r4,THREAD_LOAD_FP(r5)
|
2013-10-23 09:40:02 +01:00
|
|
|
addi r10,r5,THREAD_FPSTATE
|
|
|
|
|
lfd fr0,FPSTATE_FPSCR(r10)
|
2006-06-10 20:18:39 +10:00
|
|
|
MTFSF_L(fr0)
|
2013-10-23 09:40:02 +01:00
|
|
|
REST_32FPVSRS(0, R4, R10)
|
2005-09-26 16:04:21 +10:00
|
|
|
/* restore registers and return */
|
|
|
|
|
/* we haven't used ctr or xer or lr */
|
2008-06-25 14:07:18 +10:00
|
|
|
blr
|
2020-03-31 16:03:44 +00:00
|
|
|
_ASM_NOKPROBE_SYMBOL(load_up_fpu)
|
2005-09-26 16:04:21 +10:00
|
|
|
|
|
|
|
|
/*
|
2016-02-29 17:53:49 +11:00
|
|
|
* save_fpu(tsk)
|
|
|
|
|
* Save the floating-point registers in its thread_struct.
|
2005-09-26 16:04:21 +10:00
|
|
|
* Enables the FPU for use in the kernel on return.
|
|
|
|
|
*/
|
2016-02-29 17:53:49 +11:00
|
|
|
_GLOBAL(save_fpu)
|
2005-09-26 16:04:21 +10:00
|
|
|
addi r3,r3,THREAD /* want THREAD of task */
|
2013-09-10 20:21:10 +10:00
|
|
|
PPC_LL r6,THREAD_FPSAVEAREA(r3)
|
[PATCH] powerpc: Consolidate asm compatibility macros
This patch consolidates macros used to generate assembly for
compatibility across different CPUs or configs. A new header,
asm-powerpc/asm-compat.h contains the main compatibility macros. It
uses some preprocessor magic to make the macros suitable both for use
in .S files, and in inline asm in .c files. Headers (bitops.h,
uaccess.h, atomic.h, bug.h) which had their own such compatibility
macros are changed to use asm-compat.h.
ppc_asm.h is now for use in .S files *only*, and a #error enforces
that. As such, we're a lot more careless about namespace pollution
here than in asm-compat.h.
While we're at it, this patch adds a call to the PPC405_ERR77 macro in
futex.h which should have had it already, but didn't.
Built and booted on pSeries, Maple and iSeries (ARCH=powerpc). Built
for 32-bit powermac (ARCH=powerpc) and Walnut (ARCH=ppc).
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-10 12:56:55 +11:00
|
|
|
PPC_LL r5,PT_REGS(r3)
|
2013-09-10 20:21:10 +10:00
|
|
|
PPC_LCMPI 0,r6,0
|
|
|
|
|
bne 2f
|
2013-09-10 20:20:42 +10:00
|
|
|
addi r6,r3,THREAD_FPSTATE
|
2016-02-29 17:53:49 +11:00
|
|
|
2: SAVE_32FPVSRS(0, R4, R6)
|
2005-09-26 16:04:21 +10:00
|
|
|
mffs fr0
|
2013-09-10 20:20:42 +10:00
|
|
|
stfd fr0,FPSTATE_FPSCR(r6)
|
powerpc: Don't clobber f0/vs0 during fp|altivec register save
During floating point and vector save to thread data f0/vs0 are
clobbered by the FPSCR/VSCR store routine. This has been obvserved to
lead to userspace register corruption and application data corruption
with io-uring.
Fix it by restoring f0/vs0 after FPSCR/VSCR store has completed for
all the FP, altivec, VMX register save paths.
Tested under QEMU in kvm mode, running on a Talos II workstation with
dual POWER9 DD2.2 CPUs.
Additional detail (mpe):
Typically save_fpu() is called from __giveup_fpu() which saves the FP
regs and also *turns off FP* in the tasks MSR, meaning the kernel will
reload the FP regs from the thread struct before letting the task use FP
again. So in that case save_fpu() is free to clobber f0 because the FP
regs no longer hold live values for the task.
There is another case though, which is the path via:
sys_clone()
...
copy_process()
dup_task_struct()
arch_dup_task_struct()
flush_all_to_thread()
save_all()
That path saves the FP regs but leaves them live. That's meant as an
optimisation for a process that's using FP/VSX and then calls fork(),
leaving the regs live means the parent process doesn't have to take a
fault after the fork to get its FP regs back. The optimisation was added
in commit 8792468da5e1 ("powerpc: Add the ability to save FPU without
giving it up").
That path does clobber f0, but f0 is volatile across function calls,
and typically programs reach copy_process() from userspace via a syscall
wrapper function. So in normal usage f0 being clobbered across a
syscall doesn't cause visible data corruption.
But there is now a new path, because io-uring can call copy_process()
via create_io_thread() from the signal handling path. That's OK if the
signal is handled as part of syscall return, but it's not OK if the
signal is handled due to some other interrupt.
That path is:
interrupt_return_srr_user()
interrupt_exit_user_prepare()
interrupt_exit_user_prepare_main()
do_notify_resume()
get_signal()
task_work_run()
create_worker_cb()
create_io_worker()
copy_process()
dup_task_struct()
arch_dup_task_struct()
flush_all_to_thread()
save_all()
if (tsk->thread.regs->msr & MSR_FP)
save_fpu()
# f0 is clobbered and potentially live in userspace
Note the above discussion applies equally to save_altivec().
Fixes: 8792468da5e1 ("powerpc: Add the ability to save FPU without giving it up")
Cc: stable@vger.kernel.org # v4.6+
Closes: https://lore.kernel.org/all/480932026.45576726.1699374859845.JavaMail.zimbra@raptorengineeringinc.com/
Closes: https://lore.kernel.org/linuxppc-dev/480221078.47953493.1700206777956.JavaMail.zimbra@raptorengineeringinc.com/
Tested-by: Timothy Pearson <tpearson@raptorengineering.com>
Tested-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
[mpe: Reword change log to describe exact path of corruption & other minor tweaks]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/1921539696.48534988.1700407082933.JavaMail.zimbra@raptorengineeringinc.com
2023-11-19 09:18:02 -06:00
|
|
|
REST_1FPVSR(0, R4, R6)
|
2005-09-26 16:04:21 +10:00
|
|
|
blr
|