In irq_set_pending_from_srr1() we were missing 0x2 as system
reset identified from SRR1 caused by back to back system
resets or when interrupts are caused by SCOM when the thread
is not in power saving mode.

This helps us get to NMI handling in both the case where NMI
is caused when in power-saving and not in power-saving mode.
The actual exploitation is expected when we are doing a kdump
and an offline CPU might not be in power-saving mode due to
an already spurious IPI or any other reason.

Signed-off-by: Balbir Singh <bsinghar...@gmail.com>
---
 arch/powerpc/kernel/irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index b7a84522e652..ec89104e8ab9 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -413,7 +413,7 @@ bool prep_irq_for_idle_irqsoff(void)
 #define IRQ_SYSTEM_RESET       0xff
 
 static const u8 srr1_to_lazyirq[0x10] = {
-       0, 0, 0,
+       0, 0, IRQ_SYSTEM_RESET,
        PACA_IRQ_DBELL,
        IRQ_SYSTEM_RESET,
        PACA_IRQ_DBELL,
-- 
2.13.6

Reply via email to