On Mon, Nov 02, 2015 at 12:50:50PM -0800, Petri Gynther wrote:
> On Mon, Oct 19, 2015 at 11:49 AM, Petri Gynther <pgynther@xxxxxxxxxx> wrote:
> >
> > We need to enter NMI context when NMI interrupt fires.
> >
> > Signed-off-by: Petri Gynther <pgynther@xxxxxxxxxx>
> > ---
> > arch/mips/kernel/traps.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
> > index fdb392b..efcedd4 100644
> > --- a/arch/mips/kernel/traps.c
> > +++ b/arch/mips/kernel/traps.c
> > @@ -1856,12 +1856,14 @@ void __noreturn nmi_exception_handler(struct pt_regs *regs)
> > {
> > char str[100];
> >
> > + nmi_enter();
> > raw_notifier_call_chain(&nmi_chain, 0, regs);
> > bust_spinlocks(1);
> > snprintf(str, 100, "CPU%d NMI taken, CP0_EPC=%lx\n",
> > smp_processor_id(), regs->cp0_epc);
> > regs->cp0_epc = read_c0_errorepc();
> > die(str, regs);
> > + nmi_exit();
> > }
> >
> > #define VECTORSPACING 0x100 /* for EI/VI mode */
> > --
> > 2.6.0.rc2.230.g3dd15c0
> >
>
> Any comments/concerns about this patch?
Is NMI on your systems actually recoverable? I never bothered with
nmi_enther / nmi_exit and other fine details of the NMI implementations
because as defined by the MIPS architecture an NMI may be pretty destructive
and closer to a reset than what other architectures describer as their NMI.
Think what's going to happen if it hits during any phase when $k0 / $k1
are active.
Ralf
