The return-to-kernel path has to replay any soft-pending interrupts if it is
returning to a context that had interrupts soft-enabled. It has to do this
carefully and avoid plain enabling interrupts if this is an irq context,
which can cause multiple nesting of interrupts on the stack, and other
unexpected issues.

The code which avoided this case got the soft-mask state wrong, and
marked interrupts as enabled before going around again to retry. This
seems to be mostly harmless except when PREEMPT=y, this calls
preempt_schedule_irq with irqs apparently enabled and runs into a BUG
in kernel/sched/core.c

Signed-off-by: Nicholas Piggin <npig...@gmail.com>
---
 arch/powerpc/kernel/syscall_64.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/kernel/syscall_64.c b/arch/powerpc/kernel/syscall_64.c
index 049608d811c7..cf06eb443a80 100644
--- a/arch/powerpc/kernel/syscall_64.c
+++ b/arch/powerpc/kernel/syscall_64.c
@@ -342,11 +342,15 @@ notrace unsigned long 
interrupt_exit_kernel_prepare(struct pt_regs *regs, unsign
                        trace_hardirqs_off();
                        local_paca->irq_happened |= PACA_IRQ_HARD_DIS;
                        /*
-                        * Can't local_irq_enable in case we are in interrupt
-                        * context. Must replay directly.
+                        * Can't local_irq_restore to replay if we were in
+                        * interrupt context. Must replay directly.
                         */
-                       replay_soft_interrupts();
-                       irq_soft_mask_set(flags);
+                       if (irqs_disabled_flags(flags)) {
+                               replay_soft_interrupts();
+                       } else {
+                               local_irq_restore(flags);
+                               local_irq_save(flags);
+                       }
                        /* Took an interrupt, may have more exit work to do. */
                        goto again;
                }
-- 
2.23.0

Reply via email to