2005-04-16 22:20:36 +00:00
|
|
|
/*
|
2009-03-26 14:24:01 +00:00
|
|
|
* Machine check handler
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2012-07-20 09:15:04 +00:00
|
|
|
* Copyright IBM Corp. 2000, 2009
|
2009-03-26 14:24:01 +00:00
|
|
|
* Author(s): Ingo Adlung <adlung@de.ibm.com>,
|
|
|
|
* Martin Schwidefsky <schwidefsky@de.ibm.com>,
|
|
|
|
* Cornelia Huck <cornelia.huck@de.ibm.com>,
|
|
|
|
* Heiko Carstens <heiko.carstens@de.ibm.com>,
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
|
|
|
|
2011-01-05 11:47:28 +00:00
|
|
|
#include <linux/kernel_stat.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/errno.h>
|
2009-04-14 13:36:18 +00:00
|
|
|
#include <linux/hardirq.h>
|
2006-05-01 19:16:14 +00:00
|
|
|
#include <linux/time.h>
|
2017-02-09 20:20:23 +00:00
|
|
|
#include <linux/export.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <asm/lowcore.h>
|
2009-03-26 14:24:01 +00:00
|
|
|
#include <asm/smp.h>
|
2016-05-31 13:06:51 +00:00
|
|
|
#include <asm/stp.h>
|
2009-06-12 08:26:21 +00:00
|
|
|
#include <asm/cputime.h>
|
2009-03-26 14:24:01 +00:00
|
|
|
#include <asm/nmi.h>
|
|
|
|
#include <asm/crw.h>
|
2014-10-06 15:53:53 +00:00
|
|
|
#include <asm/switch_to.h>
|
s390/nmi: fix vector register corruption
If a machine check happens, the machine has the vector facility installed
and the extended save area exists, the cpu will save vector register
contents into the extended save area. This is regardless of control
register 0 contents, which enables and disables the vector facility during
runtime.
On each machine check we should validate the vector registers. The current
code however tries to validate the registers only if the running task is
using vector registers in user space.
However even the current code is broken and causes vector register
corruption on machine checks, if user space uses them:
the prefix area contains a pointer (absolute address) to the machine check
extended save area. In order to save some space the save area was put into
an unused area of the second prefix page.
When validating vector register contents the code uses the absolute address
of the extended save area, which is wrong. Due to prefixing the vector
instructions will then access contents using absolute addresses instead
of real addresses, where the machine stored the contents.
If the above would work there is still the problem that register validition
would only happen if user space uses vector registers. If kernel space uses
them also, this may also lead to vector register content corruption:
if the kernel makes use of vector instructions, but the current running
user space context does not, the machine check handler will validate
floating point registers instead of vector registers.
Given the fact that writing to a floating point register may change the
upper halve of the corresponding vector register, we also experience vector
register corruption in this case.
Fix all of these issues, and always validate vector registers on each
machine check, if the machine has the vector facility installed and the
extended save area is defined.
Cc: <stable@vger.kernel.org> # 4.1+
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-07-07 06:40:49 +00:00
|
|
|
#include <asm/ctl_reg.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2005-06-25 21:55:30 +00:00
|
|
|
struct mcck_struct {
|
2015-10-12 11:04:12 +00:00
|
|
|
unsigned int kill_task : 1;
|
|
|
|
unsigned int channel_report : 1;
|
|
|
|
unsigned int warning : 1;
|
2015-10-09 11:48:03 +00:00
|
|
|
unsigned int stp_queue : 1;
|
2015-10-12 11:00:39 +00:00
|
|
|
unsigned long mcck_code;
|
2005-06-25 21:55:30 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static DEFINE_PER_CPU(struct mcck_struct, cpu_mcck);
|
|
|
|
|
2015-10-12 10:39:09 +00:00
|
|
|
static void s390_handle_damage(void)
|
2009-03-26 14:24:01 +00:00
|
|
|
{
|
|
|
|
smp_send_stop();
|
|
|
|
disabled_wait((unsigned long) __builtin_return_address(0));
|
|
|
|
while (1);
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
2005-06-25 21:55:30 +00:00
|
|
|
* Main machine check handler function. Will be called with interrupts enabled
|
|
|
|
* or disabled and machine checks enabled or disabled.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2009-03-26 14:24:01 +00:00
|
|
|
void s390_handle_mcck(void)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2005-06-25 21:55:30 +00:00
|
|
|
unsigned long flags;
|
|
|
|
struct mcck_struct mcck;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2005-06-25 21:55:30 +00:00
|
|
|
/*
|
|
|
|
* Disable machine checks and get the current state of accumulated
|
|
|
|
* machine checks. Afterwards delete the old state and enable machine
|
|
|
|
* checks again.
|
|
|
|
*/
|
|
|
|
local_irq_save(flags);
|
|
|
|
local_mcck_disable();
|
2014-11-28 14:40:57 +00:00
|
|
|
mcck = *this_cpu_ptr(&cpu_mcck);
|
|
|
|
memset(this_cpu_ptr(&cpu_mcck), 0, sizeof(mcck));
|
2014-04-15 10:55:07 +00:00
|
|
|
clear_cpu_flag(CIF_MCCK_PENDING);
|
2005-06-25 21:55:30 +00:00
|
|
|
local_mcck_enable();
|
|
|
|
local_irq_restore(flags);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2005-06-25 21:55:30 +00:00
|
|
|
if (mcck.channel_report)
|
2009-03-26 14:24:01 +00:00
|
|
|
crw_handle_channel_report();
|
2009-03-26 14:24:02 +00:00
|
|
|
/*
|
|
|
|
* A warning may remain for a prolonged period on the bare iron.
|
|
|
|
* (actually until the machine is powered off, or the problem is gone)
|
|
|
|
* So we just stop listening for the WARNING MCH and avoid continuously
|
|
|
|
* being interrupted. One caveat is however, that we must do this per
|
|
|
|
* processor and cannot use the smp version of ctl_clear_bit().
|
|
|
|
* On VM we only get one interrupt per virtally presented machinecheck.
|
|
|
|
* Though one suffices, we may get one interrupt per (virtual) cpu.
|
|
|
|
*/
|
2005-06-25 21:55:30 +00:00
|
|
|
if (mcck.warning) { /* WARNING pending ? */
|
2005-04-16 22:20:36 +00:00
|
|
|
static int mchchk_wng_posted = 0;
|
2009-03-26 14:24:02 +00:00
|
|
|
|
|
|
|
/* Use single cpu clear, as we cannot handle smp here. */
|
2005-04-16 22:20:36 +00:00
|
|
|
__ctl_clear_bit(14, 24); /* Disable WARNING MCH */
|
|
|
|
if (xchg(&mchchk_wng_posted, 1) == 0)
|
2006-10-02 09:19:00 +00:00
|
|
|
kill_cad_pid(SIGPWR, 1);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2015-10-09 11:48:03 +00:00
|
|
|
if (mcck.stp_queue)
|
|
|
|
stp_queue_work();
|
2005-06-25 21:55:30 +00:00
|
|
|
if (mcck.kill_task) {
|
|
|
|
local_irq_enable();
|
|
|
|
printk(KERN_EMERG "mcck: Terminating task because of machine "
|
2015-10-12 11:00:39 +00:00
|
|
|
"malfunction (code 0x%016lx).\n", mcck.mcck_code);
|
2005-06-25 21:55:30 +00:00
|
|
|
printk(KERN_EMERG "mcck: task: %s, pid: %d.\n",
|
|
|
|
current->comm, current->pid);
|
|
|
|
do_exit(SIGSEGV);
|
|
|
|
}
|
|
|
|
}
|
2008-05-21 11:37:34 +00:00
|
|
|
EXPORT_SYMBOL_GPL(s390_handle_mcck);
|
2005-06-25 21:55:30 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* returns 0 if all registers could be validated
|
|
|
|
* returns 1 otherwise
|
|
|
|
*/
|
2016-08-22 12:40:06 +00:00
|
|
|
static int notrace s390_validate_registers(union mci mci, int umode)
|
2005-06-25 21:55:30 +00:00
|
|
|
{
|
|
|
|
int kill_task;
|
|
|
|
u64 zero;
|
2016-12-13 11:42:07 +00:00
|
|
|
void *fpt_save_area;
|
2005-06-25 21:55:30 +00:00
|
|
|
|
|
|
|
kill_task = 0;
|
|
|
|
zero = 0;
|
2009-03-26 14:24:01 +00:00
|
|
|
|
2015-10-12 11:00:39 +00:00
|
|
|
if (!mci.gr) {
|
2005-06-25 21:55:30 +00:00
|
|
|
/*
|
|
|
|
* General purpose registers couldn't be restored and have
|
2016-08-22 12:40:06 +00:00
|
|
|
* unknown contents. Stop system or terminate process.
|
2005-06-25 21:55:30 +00:00
|
|
|
*/
|
2016-08-22 12:40:06 +00:00
|
|
|
if (!umode)
|
|
|
|
s390_handle_damage();
|
2005-06-25 21:55:30 +00:00
|
|
|
kill_task = 1;
|
2009-03-26 14:24:01 +00:00
|
|
|
}
|
2017-02-21 09:51:55 +00:00
|
|
|
/* Validate control registers */
|
|
|
|
if (!mci.cr) {
|
|
|
|
/*
|
|
|
|
* Control registers have unknown contents.
|
|
|
|
* Can't recover and therefore stopping machine.
|
|
|
|
*/
|
|
|
|
s390_handle_damage();
|
|
|
|
} else {
|
|
|
|
asm volatile(
|
2017-02-21 10:07:39 +00:00
|
|
|
" lctlg 0,15,0(%0)\n"
|
|
|
|
" ptlb\n"
|
2017-02-21 09:51:55 +00:00
|
|
|
: : "a" (&S390_lowcore.cregs_save_area) : "memory");
|
|
|
|
}
|
2015-10-12 11:00:39 +00:00
|
|
|
if (!mci.fp) {
|
2005-06-25 21:55:30 +00:00
|
|
|
/*
|
2016-08-22 12:40:06 +00:00
|
|
|
* Floating point registers can't be restored. If the
|
|
|
|
* kernel currently uses floating point registers the
|
|
|
|
* system is stopped. If the process has its floating
|
|
|
|
* pointer registers loaded it is terminated.
|
|
|
|
* Otherwise just revalidate the registers.
|
2005-06-25 21:55:30 +00:00
|
|
|
*/
|
2016-08-22 12:40:06 +00:00
|
|
|
if (S390_lowcore.fpu_flags & KERNEL_VXR_V0V7)
|
|
|
|
s390_handle_damage();
|
|
|
|
if (!test_cpu_flag(CIF_FPU))
|
|
|
|
kill_task = 1;
|
2009-03-26 14:24:01 +00:00
|
|
|
}
|
2015-02-12 12:08:27 +00:00
|
|
|
fpt_save_area = &S390_lowcore.floating_pt_save_area;
|
2015-10-12 11:00:39 +00:00
|
|
|
if (!mci.fc) {
|
2015-02-12 12:08:27 +00:00
|
|
|
/*
|
|
|
|
* Floating point control register can't be restored.
|
2016-08-22 12:40:06 +00:00
|
|
|
* If the kernel currently uses the floating pointer
|
|
|
|
* registers and needs the FPC register the system is
|
|
|
|
* stopped. If the process has its floating pointer
|
|
|
|
* registers loaded it is terminated. Otherwiese the
|
|
|
|
* FPC is just revalidated.
|
2015-02-12 12:08:27 +00:00
|
|
|
*/
|
2016-08-22 12:40:06 +00:00
|
|
|
if (S390_lowcore.fpu_flags & KERNEL_FPC)
|
|
|
|
s390_handle_damage();
|
2016-12-13 11:42:07 +00:00
|
|
|
asm volatile("lfpc %0" : : "Q" (zero));
|
2016-08-22 12:40:06 +00:00
|
|
|
if (!test_cpu_flag(CIF_FPU))
|
|
|
|
kill_task = 1;
|
2016-12-13 11:42:07 +00:00
|
|
|
} else {
|
|
|
|
asm volatile("lfpc %0"
|
|
|
|
: : "Q" (S390_lowcore.fpt_creg_save_area));
|
|
|
|
}
|
2015-02-12 12:08:27 +00:00
|
|
|
|
s390/nmi: fix vector register corruption
If a machine check happens, the machine has the vector facility installed
and the extended save area exists, the cpu will save vector register
contents into the extended save area. This is regardless of control
register 0 contents, which enables and disables the vector facility during
runtime.
On each machine check we should validate the vector registers. The current
code however tries to validate the registers only if the running task is
using vector registers in user space.
However even the current code is broken and causes vector register
corruption on machine checks, if user space uses them:
the prefix area contains a pointer (absolute address) to the machine check
extended save area. In order to save some space the save area was put into
an unused area of the second prefix page.
When validating vector register contents the code uses the absolute address
of the extended save area, which is wrong. Due to prefixing the vector
instructions will then access contents using absolute addresses instead
of real addresses, where the machine stored the contents.
If the above would work there is still the problem that register validition
would only happen if user space uses vector registers. If kernel space uses
them also, this may also lead to vector register content corruption:
if the kernel makes use of vector instructions, but the current running
user space context does not, the machine check handler will validate
floating point registers instead of vector registers.
Given the fact that writing to a floating point register may change the
upper halve of the corresponding vector register, we also experience vector
register corruption in this case.
Fix all of these issues, and always validate vector registers on each
machine check, if the machine has the vector facility installed and the
extended save area is defined.
Cc: <stable@vger.kernel.org> # 4.1+
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-07-07 06:40:49 +00:00
|
|
|
if (!MACHINE_HAS_VX) {
|
2015-10-12 11:03:05 +00:00
|
|
|
/* Validate floating point registers */
|
s390/nmi: fix vector register corruption
If a machine check happens, the machine has the vector facility installed
and the extended save area exists, the cpu will save vector register
contents into the extended save area. This is regardless of control
register 0 contents, which enables and disables the vector facility during
runtime.
On each machine check we should validate the vector registers. The current
code however tries to validate the registers only if the running task is
using vector registers in user space.
However even the current code is broken and causes vector register
corruption on machine checks, if user space uses them:
the prefix area contains a pointer (absolute address) to the machine check
extended save area. In order to save some space the save area was put into
an unused area of the second prefix page.
When validating vector register contents the code uses the absolute address
of the extended save area, which is wrong. Due to prefixing the vector
instructions will then access contents using absolute addresses instead
of real addresses, where the machine stored the contents.
If the above would work there is still the problem that register validition
would only happen if user space uses vector registers. If kernel space uses
them also, this may also lead to vector register content corruption:
if the kernel makes use of vector instructions, but the current running
user space context does not, the machine check handler will validate
floating point registers instead of vector registers.
Given the fact that writing to a floating point register may change the
upper halve of the corresponding vector register, we also experience vector
register corruption in this case.
Fix all of these issues, and always validate vector registers on each
machine check, if the machine has the vector facility installed and the
extended save area is defined.
Cc: <stable@vger.kernel.org> # 4.1+
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-07-07 06:40:49 +00:00
|
|
|
asm volatile(
|
|
|
|
" ld 0,0(%0)\n"
|
|
|
|
" ld 1,8(%0)\n"
|
|
|
|
" ld 2,16(%0)\n"
|
|
|
|
" ld 3,24(%0)\n"
|
|
|
|
" ld 4,32(%0)\n"
|
|
|
|
" ld 5,40(%0)\n"
|
|
|
|
" ld 6,48(%0)\n"
|
|
|
|
" ld 7,56(%0)\n"
|
|
|
|
" ld 8,64(%0)\n"
|
|
|
|
" ld 9,72(%0)\n"
|
|
|
|
" ld 10,80(%0)\n"
|
|
|
|
" ld 11,88(%0)\n"
|
|
|
|
" ld 12,96(%0)\n"
|
|
|
|
" ld 13,104(%0)\n"
|
|
|
|
" ld 14,112(%0)\n"
|
|
|
|
" ld 15,120(%0)\n"
|
2016-12-13 11:42:07 +00:00
|
|
|
: : "a" (fpt_save_area) : "memory");
|
s390/nmi: fix vector register corruption
If a machine check happens, the machine has the vector facility installed
and the extended save area exists, the cpu will save vector register
contents into the extended save area. This is regardless of control
register 0 contents, which enables and disables the vector facility during
runtime.
On each machine check we should validate the vector registers. The current
code however tries to validate the registers only if the running task is
using vector registers in user space.
However even the current code is broken and causes vector register
corruption on machine checks, if user space uses them:
the prefix area contains a pointer (absolute address) to the machine check
extended save area. In order to save some space the save area was put into
an unused area of the second prefix page.
When validating vector register contents the code uses the absolute address
of the extended save area, which is wrong. Due to prefixing the vector
instructions will then access contents using absolute addresses instead
of real addresses, where the machine stored the contents.
If the above would work there is still the problem that register validition
would only happen if user space uses vector registers. If kernel space uses
them also, this may also lead to vector register content corruption:
if the kernel makes use of vector instructions, but the current running
user space context does not, the machine check handler will validate
floating point registers instead of vector registers.
Given the fact that writing to a floating point register may change the
upper halve of the corresponding vector register, we also experience vector
register corruption in this case.
Fix all of these issues, and always validate vector registers on each
machine check, if the machine has the vector facility installed and the
extended save area is defined.
Cc: <stable@vger.kernel.org> # 4.1+
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-07-07 06:40:49 +00:00
|
|
|
} else {
|
2015-10-12 11:03:05 +00:00
|
|
|
/* Validate vector registers */
|
s390/nmi: fix vector register corruption
If a machine check happens, the machine has the vector facility installed
and the extended save area exists, the cpu will save vector register
contents into the extended save area. This is regardless of control
register 0 contents, which enables and disables the vector facility during
runtime.
On each machine check we should validate the vector registers. The current
code however tries to validate the registers only if the running task is
using vector registers in user space.
However even the current code is broken and causes vector register
corruption on machine checks, if user space uses them:
the prefix area contains a pointer (absolute address) to the machine check
extended save area. In order to save some space the save area was put into
an unused area of the second prefix page.
When validating vector register contents the code uses the absolute address
of the extended save area, which is wrong. Due to prefixing the vector
instructions will then access contents using absolute addresses instead
of real addresses, where the machine stored the contents.
If the above would work there is still the problem that register validition
would only happen if user space uses vector registers. If kernel space uses
them also, this may also lead to vector register content corruption:
if the kernel makes use of vector instructions, but the current running
user space context does not, the machine check handler will validate
floating point registers instead of vector registers.
Given the fact that writing to a floating point register may change the
upper halve of the corresponding vector register, we also experience vector
register corruption in this case.
Fix all of these issues, and always validate vector registers on each
machine check, if the machine has the vector facility installed and the
extended save area is defined.
Cc: <stable@vger.kernel.org> # 4.1+
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-07-07 06:40:49 +00:00
|
|
|
union ctlreg0 cr0;
|
|
|
|
|
2015-10-12 11:00:39 +00:00
|
|
|
if (!mci.vr) {
|
2014-10-06 15:53:53 +00:00
|
|
|
/*
|
2016-08-22 12:40:06 +00:00
|
|
|
* Vector registers can't be restored. If the kernel
|
|
|
|
* currently uses vector registers the system is
|
|
|
|
* stopped. If the process has its vector registers
|
|
|
|
* loaded it is terminated. Otherwise just revalidate
|
|
|
|
* the registers.
|
2014-10-06 15:53:53 +00:00
|
|
|
*/
|
2016-08-22 12:40:06 +00:00
|
|
|
if (S390_lowcore.fpu_flags & KERNEL_VXR)
|
|
|
|
s390_handle_damage();
|
|
|
|
if (!test_cpu_flag(CIF_FPU))
|
|
|
|
kill_task = 1;
|
2014-10-06 15:53:53 +00:00
|
|
|
}
|
s390/nmi: fix vector register corruption
If a machine check happens, the machine has the vector facility installed
and the extended save area exists, the cpu will save vector register
contents into the extended save area. This is regardless of control
register 0 contents, which enables and disables the vector facility during
runtime.
On each machine check we should validate the vector registers. The current
code however tries to validate the registers only if the running task is
using vector registers in user space.
However even the current code is broken and causes vector register
corruption on machine checks, if user space uses them:
the prefix area contains a pointer (absolute address) to the machine check
extended save area. In order to save some space the save area was put into
an unused area of the second prefix page.
When validating vector register contents the code uses the absolute address
of the extended save area, which is wrong. Due to prefixing the vector
instructions will then access contents using absolute addresses instead
of real addresses, where the machine stored the contents.
If the above would work there is still the problem that register validition
would only happen if user space uses vector registers. If kernel space uses
them also, this may also lead to vector register content corruption:
if the kernel makes use of vector instructions, but the current running
user space context does not, the machine check handler will validate
floating point registers instead of vector registers.
Given the fact that writing to a floating point register may change the
upper halve of the corresponding vector register, we also experience vector
register corruption in this case.
Fix all of these issues, and always validate vector registers on each
machine check, if the machine has the vector facility installed and the
extended save area is defined.
Cc: <stable@vger.kernel.org> # 4.1+
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-07-07 06:40:49 +00:00
|
|
|
cr0.val = S390_lowcore.cregs_save_area[0];
|
|
|
|
cr0.afp = cr0.vx = 1;
|
|
|
|
__ctl_load(cr0.val, 0, 0);
|
s390/kernel: lazy restore fpu registers
Improve the save and restore behavior of FPU register contents to use the
vector extension within the kernel.
The kernel does not use floating-point or vector registers and, therefore,
saving and restoring the FPU register contents are performed for handling
signals or switching processes only. To prepare for using vector
instructions and vector registers within the kernel, enhance the save
behavior and implement a lazy restore at return to user space from a
system call or interrupt.
To implement the lazy restore, the save_fpu_regs() sets a CPU information
flag, CIF_FPU, to indicate that the FPU registers must be restored.
Saving and setting CIF_FPU is performed in an atomic fashion to be
interrupt-safe. When the kernel wants to use the vector extension or
wants to change the FPU register state for a task during signal handling,
the save_fpu_regs() must be called first. The CIF_FPU flag is also set at
process switch. At return to user space, the FPU state is restored. In
particular, the FPU state includes the floating-point or vector register
contents, as well as, vector-enablement and floating-point control. The
FPU state restore and clearing CIF_FPU is also performed in an atomic
fashion.
For KVM, the restore of the FPU register state is performed when restoring
the general-purpose guest registers before the SIE instructions is started.
Because the path towards the SIE instruction is interruptible, the CIF_FPU
flag must be checked again right before going into SIE. If set, the guest
registers must be reloaded again by re-entering the outer SIE loop. This
is the same behavior as if the SIE critical section is interrupted.
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-06-10 10:53:42 +00:00
|
|
|
asm volatile(
|
|
|
|
" la 1,%0\n"
|
|
|
|
" .word 0xe70f,0x1000,0x0036\n" /* vlm 0,15,0(1) */
|
|
|
|
" .word 0xe70f,0x1100,0x0c36\n" /* vlm 16,31,256(1) */
|
|
|
|
: : "Q" (*(struct vx_array *)
|
|
|
|
&S390_lowcore.vector_save_area) : "1");
|
s390/nmi: fix vector register corruption
If a machine check happens, the machine has the vector facility installed
and the extended save area exists, the cpu will save vector register
contents into the extended save area. This is regardless of control
register 0 contents, which enables and disables the vector facility during
runtime.
On each machine check we should validate the vector registers. The current
code however tries to validate the registers only if the running task is
using vector registers in user space.
However even the current code is broken and causes vector register
corruption on machine checks, if user space uses them:
the prefix area contains a pointer (absolute address) to the machine check
extended save area. In order to save some space the save area was put into
an unused area of the second prefix page.
When validating vector register contents the code uses the absolute address
of the extended save area, which is wrong. Due to prefixing the vector
instructions will then access contents using absolute addresses instead
of real addresses, where the machine stored the contents.
If the above would work there is still the problem that register validition
would only happen if user space uses vector registers. If kernel space uses
them also, this may also lead to vector register content corruption:
if the kernel makes use of vector instructions, but the current running
user space context does not, the machine check handler will validate
floating point registers instead of vector registers.
Given the fact that writing to a floating point register may change the
upper halve of the corresponding vector register, we also experience vector
register corruption in this case.
Fix all of these issues, and always validate vector registers on each
machine check, if the machine has the vector facility installed and the
extended save area is defined.
Cc: <stable@vger.kernel.org> # 4.1+
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-07-07 06:40:49 +00:00
|
|
|
__ctl_load(S390_lowcore.cregs_save_area[0], 0, 0);
|
2014-10-06 15:53:53 +00:00
|
|
|
}
|
2015-10-12 11:03:05 +00:00
|
|
|
/* Validate access registers */
|
2006-09-28 14:56:43 +00:00
|
|
|
asm volatile(
|
|
|
|
" lam 0,15,0(%0)"
|
|
|
|
: : "a" (&S390_lowcore.access_regs_save_area));
|
2015-10-12 11:00:39 +00:00
|
|
|
if (!mci.ar) {
|
2005-06-25 21:55:30 +00:00
|
|
|
/*
|
|
|
|
* Access registers have unknown contents.
|
|
|
|
* Terminating task.
|
|
|
|
*/
|
|
|
|
kill_task = 1;
|
2009-03-26 14:24:01 +00:00
|
|
|
}
|
2005-06-25 21:55:30 +00:00
|
|
|
/*
|
2015-10-12 11:03:05 +00:00
|
|
|
* We don't even try to validate the TOD register, since we simply
|
2005-06-25 21:55:30 +00:00
|
|
|
* can't write something sensible into that register.
|
|
|
|
*/
|
|
|
|
/*
|
2015-10-12 11:03:05 +00:00
|
|
|
* See if we can validate the TOD programmable register with its
|
2005-06-25 21:55:30 +00:00
|
|
|
* old contents (should be zero) otherwise set it to zero.
|
|
|
|
*/
|
2015-10-12 11:00:39 +00:00
|
|
|
if (!mci.pr)
|
2006-09-28 14:56:43 +00:00
|
|
|
asm volatile(
|
|
|
|
" sr 0,0\n"
|
|
|
|
" sckpf"
|
|
|
|
: : : "0", "cc");
|
2005-06-25 21:55:30 +00:00
|
|
|
else
|
|
|
|
asm volatile(
|
2016-12-13 11:42:07 +00:00
|
|
|
" l 0,%0\n"
|
2006-09-28 14:56:43 +00:00
|
|
|
" sckpf"
|
2016-12-13 11:42:07 +00:00
|
|
|
: : "Q" (S390_lowcore.tod_progreg_save_area)
|
2006-09-28 14:56:43 +00:00
|
|
|
: "0", "cc");
|
2015-10-12 11:03:05 +00:00
|
|
|
/* Validate clock comparator register */
|
2013-08-08 10:37:00 +00:00
|
|
|
set_clock_comparator(S390_lowcore.clock_comparator);
|
2005-06-25 21:55:30 +00:00
|
|
|
/* Check if old PSW is valid */
|
2015-10-12 11:00:39 +00:00
|
|
|
if (!mci.wp)
|
2005-06-25 21:55:30 +00:00
|
|
|
/*
|
|
|
|
* Can't tell if we come from user or kernel mode
|
|
|
|
* -> stopping machine.
|
|
|
|
*/
|
2015-10-12 10:39:09 +00:00
|
|
|
s390_handle_damage();
|
2005-06-25 21:55:30 +00:00
|
|
|
|
2015-10-12 11:00:39 +00:00
|
|
|
if (!mci.ms || !mci.pm || !mci.ia)
|
2005-06-25 21:55:30 +00:00
|
|
|
kill_task = 1;
|
|
|
|
|
|
|
|
return kill_task;
|
|
|
|
}
|
|
|
|
|
2006-04-28 01:40:23 +00:00
|
|
|
#define MAX_IPD_COUNT 29
|
2006-05-01 19:16:14 +00:00
|
|
|
#define MAX_IPD_TIME (5 * 60 * USEC_PER_SEC) /* 5 minutes */
|
2006-04-28 01:40:23 +00:00
|
|
|
|
2009-03-26 14:24:01 +00:00
|
|
|
#define ED_STP_ISLAND 6 /* External damage STP island check */
|
|
|
|
#define ED_STP_SYNC 7 /* External damage STP sync check */
|
|
|
|
|
2005-06-25 21:55:30 +00:00
|
|
|
/*
|
|
|
|
* machine check handler.
|
|
|
|
*/
|
2009-03-26 14:23:59 +00:00
|
|
|
void notrace s390_do_machine_check(struct pt_regs *regs)
|
2005-06-25 21:55:30 +00:00
|
|
|
{
|
2009-03-26 14:24:01 +00:00
|
|
|
static int ipd_count;
|
2006-04-28 01:40:23 +00:00
|
|
|
static DEFINE_SPINLOCK(ipd_lock);
|
|
|
|
static unsigned long long last_ipd;
|
2009-03-26 14:24:01 +00:00
|
|
|
struct mcck_struct *mcck;
|
2006-04-28 01:40:23 +00:00
|
|
|
unsigned long long tmp;
|
2015-10-12 11:00:39 +00:00
|
|
|
union mci mci;
|
2005-06-25 21:55:30 +00:00
|
|
|
|
2009-04-14 13:36:18 +00:00
|
|
|
nmi_enter();
|
2013-01-02 14:18:18 +00:00
|
|
|
inc_irq_stat(NMI_NMI);
|
2015-10-12 11:00:39 +00:00
|
|
|
mci.val = S390_lowcore.mcck_interruption_code;
|
s390: Replace __get_cpu_var uses
__get_cpu_var() is used for multiple purposes in the kernel source. One of
them is address calculation via the form &__get_cpu_var(x). This calculates
the address for the instance of the percpu variable of the current processor
based on an offset.
Other use cases are for storing and retrieving data from the current
processors percpu area. __get_cpu_var() can be used as an lvalue when
writing data or on the right side of an assignment.
__get_cpu_var() is defined as :
#define __get_cpu_var(var) (*this_cpu_ptr(&(var)))
__get_cpu_var() always only does an address determination. However, store
and retrieve operations could use a segment prefix (or global register on
other platforms) to avoid the address calculation.
this_cpu_write() and this_cpu_read() can directly take an offset into a
percpu area and use optimized assembly code to read and write per cpu
variables.
This patch converts __get_cpu_var into either an explicit address
calculation using this_cpu_ptr() or into a use of this_cpu operations that
use the offset. Thereby address calculations are avoided and less registers
are used when code is generated.
At the end of the patch set all uses of __get_cpu_var have been removed so
the macro is removed too.
The patch set includes passes over all arches as well. Once these operations
are used throughout then specialized macros can be defined in non -x86
arches as well in order to optimize per cpu access by f.e. using a global
register that may be set to the per cpu base.
Transformations done to __get_cpu_var()
1. Determine the address of the percpu instance of the current processor.
DEFINE_PER_CPU(int, y);
int *x = &__get_cpu_var(y);
Converts to
int *x = this_cpu_ptr(&y);
2. Same as #1 but this time an array structure is involved.
DEFINE_PER_CPU(int, y[20]);
int *x = __get_cpu_var(y);
Converts to
int *x = this_cpu_ptr(y);
3. Retrieve the content of the current processors instance of a per cpu
variable.
DEFINE_PER_CPU(int, y);
int x = __get_cpu_var(y)
Converts to
int x = __this_cpu_read(y);
4. Retrieve the content of a percpu struct
DEFINE_PER_CPU(struct mystruct, y);
struct mystruct x = __get_cpu_var(y);
Converts to
memcpy(&x, this_cpu_ptr(&y), sizeof(x));
5. Assignment to a per cpu variable
DEFINE_PER_CPU(int, y)
__get_cpu_var(y) = x;
Converts to
this_cpu_write(y, x);
6. Increment/Decrement etc of a per cpu variable
DEFINE_PER_CPU(int, y);
__get_cpu_var(y)++
Converts to
this_cpu_inc(y)
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
CC: linux390@de.ibm.com
Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Christoph Lameter <cl@linux.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
2014-08-17 17:30:45 +00:00
|
|
|
mcck = this_cpu_ptr(&cpu_mcck);
|
2005-06-25 21:55:30 +00:00
|
|
|
|
2015-10-12 11:00:39 +00:00
|
|
|
if (mci.sd) {
|
2005-06-25 21:55:30 +00:00
|
|
|
/* System damage -> stopping machine */
|
2015-10-12 10:39:09 +00:00
|
|
|
s390_handle_damage();
|
2009-03-26 14:24:01 +00:00
|
|
|
}
|
2015-10-12 11:00:39 +00:00
|
|
|
if (mci.pd) {
|
|
|
|
if (mci.b) {
|
2005-06-25 21:55:30 +00:00
|
|
|
/* Processing backup -> verify if we can survive this */
|
|
|
|
u64 z_mcic, o_mcic, t_mcic;
|
|
|
|
z_mcic = (1ULL<<63 | 1ULL<<59 | 1ULL<<29);
|
|
|
|
o_mcic = (1ULL<<43 | 1ULL<<42 | 1ULL<<41 | 1ULL<<40 |
|
|
|
|
1ULL<<36 | 1ULL<<35 | 1ULL<<34 | 1ULL<<32 |
|
|
|
|
1ULL<<30 | 1ULL<<21 | 1ULL<<20 | 1ULL<<17 |
|
|
|
|
1ULL<<16);
|
2015-10-12 11:00:39 +00:00
|
|
|
t_mcic = mci.val;
|
2005-06-25 21:55:30 +00:00
|
|
|
|
|
|
|
if (((t_mcic & z_mcic) != 0) ||
|
|
|
|
((t_mcic & o_mcic) != o_mcic)) {
|
2015-10-12 10:39:09 +00:00
|
|
|
s390_handle_damage();
|
2005-06-25 21:55:30 +00:00
|
|
|
}
|
2006-04-28 01:40:23 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Nullifying exigent condition, therefore we might
|
|
|
|
* retry this instruction.
|
|
|
|
*/
|
|
|
|
spin_lock(&ipd_lock);
|
2013-01-30 08:49:40 +00:00
|
|
|
tmp = get_tod_clock();
|
2006-04-28 01:40:23 +00:00
|
|
|
if (((tmp - last_ipd) >> 12) < MAX_IPD_TIME)
|
|
|
|
ipd_count++;
|
|
|
|
else
|
|
|
|
ipd_count = 1;
|
|
|
|
last_ipd = tmp;
|
|
|
|
if (ipd_count == MAX_IPD_COUNT)
|
2015-10-12 10:39:09 +00:00
|
|
|
s390_handle_damage();
|
2006-04-28 01:40:23 +00:00
|
|
|
spin_unlock(&ipd_lock);
|
2009-03-26 14:24:01 +00:00
|
|
|
} else {
|
2005-06-25 21:55:30 +00:00
|
|
|
/* Processing damage -> stopping machine */
|
2015-10-12 10:39:09 +00:00
|
|
|
s390_handle_damage();
|
2005-06-25 21:55:30 +00:00
|
|
|
}
|
|
|
|
}
|
2016-08-22 12:40:06 +00:00
|
|
|
if (s390_validate_registers(mci, user_mode(regs))) {
|
|
|
|
/*
|
|
|
|
* Couldn't restore all register contents for the
|
|
|
|
* user space process -> mark task for termination.
|
|
|
|
*/
|
|
|
|
mcck->kill_task = 1;
|
|
|
|
mcck->mcck_code = mci.val;
|
|
|
|
set_cpu_flag(CIF_MCCK_PENDING);
|
2005-06-25 21:55:30 +00:00
|
|
|
}
|
2015-10-12 11:00:39 +00:00
|
|
|
if (mci.cd) {
|
2007-02-05 20:18:19 +00:00
|
|
|
/* Timing facility damage */
|
2015-10-12 10:39:09 +00:00
|
|
|
s390_handle_damage();
|
2007-02-05 20:18:19 +00:00
|
|
|
}
|
2015-10-12 11:00:39 +00:00
|
|
|
if (mci.ed && mci.ec) {
|
2007-02-05 20:18:19 +00:00
|
|
|
/* External damage */
|
2008-07-14 07:58:56 +00:00
|
|
|
if (S390_lowcore.external_damage_code & (1U << ED_STP_SYNC))
|
2015-10-09 11:48:03 +00:00
|
|
|
mcck->stp_queue |= stp_sync_check();
|
2008-07-14 07:58:56 +00:00
|
|
|
if (S390_lowcore.external_damage_code & (1U << ED_STP_ISLAND))
|
2015-10-09 11:48:03 +00:00
|
|
|
mcck->stp_queue |= stp_island_check();
|
2016-05-31 13:06:51 +00:00
|
|
|
if (mcck->stp_queue)
|
2015-10-09 11:48:03 +00:00
|
|
|
set_cpu_flag(CIF_MCCK_PENDING);
|
2007-02-05 20:18:19 +00:00
|
|
|
}
|
2015-10-12 11:00:39 +00:00
|
|
|
if (mci.se)
|
2005-06-25 21:55:30 +00:00
|
|
|
/* Storage error uncorrected */
|
2015-10-12 10:39:09 +00:00
|
|
|
s390_handle_damage();
|
2015-10-12 11:00:39 +00:00
|
|
|
if (mci.ke)
|
2005-06-25 21:55:30 +00:00
|
|
|
/* Storage key-error uncorrected */
|
2015-10-12 10:39:09 +00:00
|
|
|
s390_handle_damage();
|
2015-10-12 11:00:39 +00:00
|
|
|
if (mci.ds && mci.fa)
|
2005-06-25 21:55:30 +00:00
|
|
|
/* Storage degradation */
|
2015-10-12 10:39:09 +00:00
|
|
|
s390_handle_damage();
|
2015-10-12 11:00:39 +00:00
|
|
|
if (mci.cp) {
|
2005-06-25 21:55:30 +00:00
|
|
|
/* Channel report word pending */
|
|
|
|
mcck->channel_report = 1;
|
2014-04-15 10:55:07 +00:00
|
|
|
set_cpu_flag(CIF_MCCK_PENDING);
|
2005-06-25 21:55:30 +00:00
|
|
|
}
|
2015-10-12 11:00:39 +00:00
|
|
|
if (mci.w) {
|
2005-06-25 21:55:30 +00:00
|
|
|
/* Warning pending */
|
|
|
|
mcck->warning = 1;
|
2014-04-15 10:55:07 +00:00
|
|
|
set_cpu_flag(CIF_MCCK_PENDING);
|
2005-06-25 21:55:30 +00:00
|
|
|
}
|
2009-04-14 13:36:18 +00:00
|
|
|
nmi_exit();
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2009-03-26 14:24:01 +00:00
|
|
|
static int __init machine_check_init(void)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2007-02-05 20:18:19 +00:00
|
|
|
ctl_set_bit(14, 25); /* enable external damage MCH */
|
2009-03-26 14:24:01 +00:00
|
|
|
ctl_set_bit(14, 27); /* enable system recovery MCH */
|
2005-04-16 22:20:36 +00:00
|
|
|
ctl_set_bit(14, 24); /* enable warning MCH */
|
|
|
|
return 0;
|
|
|
|
}
|
2015-08-17 06:09:17 +00:00
|
|
|
early_initcall(machine_check_init);
|