Re: [breakage] panic() does not halt arm64 systems under certain conditions
From: Will Deacon <will@kernel.org>
Date: 2019-09-30 13:53:13
Also in:
linux-arch, lkml
On Fri, Sep 20, 2019 at 02:25:01PM +1000, Jookia wrote:
quoted hunk ↗ jump to hunk
On Tue, Sep 17, 2019 at 11:45:19AM +0100, Will Deacon wrote:quoted
A straightforward fix is to disable preemption explicitly on the panic() path (diff below), but I've expanded the cc list to see both what others think, but also in case smp_send_stop() is supposed to have the side-effect of disabling interrupt delivery for the local CPU.diff --git a/kernel/panic.c b/kernel/panic.c index 057540b6eee9..02d0de31c42d 100644 --- a/kernel/panic.c +++ b/kernel/panic.c@@ -179,6 +179,7 @@ void panic(const char *fmt, ...)* after setting panic_cpu) from invoking panic() again. */ local_irq_disable(); + preempt_disable_notrace(); /* * It's possible to come here directly from a panic-assertion andWhen you run with panic=... it will send you to a loop earlier in the panic code before local_irq_disable() is hit, working around the bug. A patch like this would make the behaviour the same:diff --git a/kernel/panic.c b/kernel/panic.c index 4d9f55bf7d38..92abbb5f8d38 100644 --- a/kernel/panic.c +++ b/kernel/panic.c@@ -331,7 +331,6 @@ void panic(const char *fmt, ...) /* Do not scroll important messages printed above */ suppress_printk = 1; - local_irq_enable(); for (i = 0; ; i += PANIC_TIMER_STEP) { touch_softlockup_watchdog(); if (i >= i_next) {
The reason I kept irqs enabled is because I figured they might be useful for magic sysrq keyboard interrupts (e.g. if you wanted to reboot the box). With 'panic=', the reboot happens automatically, so there's no issue there afaict. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel