[PATCH v2] MIPS: SGI-IP27: print the NMI dump on an nbcon console

[PATCH v2] MIPS: SGI-IP27: print the NMI dump on an nbcon console

[Imre Kaloz]

Since the 8250 console became nbcon, printk() in nmi_dump() only queues
records for a printer thread that never runs, as no CPU leaves the NMI
handler. Print from an emergency section and flush pending records
before the hub reset.

Fixes: d3539347022a ("serial: 8250: Switch to nbcon console, take 2")
Signed-off-by: Imre Kaloz <kaloz@kernel.org>
---
v2: flush pending records before the hub reset (John Ogness)
v1: https://lore.kernel.org/all/20261001155013.1694-1-kaloz@kernel.org/

This conflicts by context with patch 14/38 of the IP35 series,
https://lore.kernel.org/all/76f2a9c32eba23de36817f0a186def01e009e1c7.1790857966.git.kaloz@kernel.org/
which rewrites the reset write. Whichever lands second places the
printk_trigger_flush() call above the system_is_ip35 branch.

 arch/mips/sgi-ip27/ip27-nmi.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/mips/sgi-ip27/ip27-nmi.c b/arch/mips/sgi-ip27/ip27-nmi.c
index fc2816398d0c..c502982621e6 100644
--- a/arch/mips/sgi-ip27/ip27-nmi.c
+++ b/arch/mips/sgi-ip27/ip27-nmi.c
@@ -1,4 +1,5 @@
 // SPDX-License-Identifier: GPL-2.0
+#include <linux/console.h>
 #include <linux/kernel.h>
 #include <linux/mmzone.h>
 #include <linux/nodemask.h>
@@ -183,6 +184,12 @@ static void nmi_dump(void)
 	 */
 	arch_spin_lock(&nmi_lock);
 
+	/*
+	 * No CPU leaves the NMI handler before the hub reset below, so an
+	 * nbcon console's printer thread would never print the dump.
+	 */
+	nbcon_cpu_emergency_enter();
+
 #ifdef REAL_NMI_SIGNAL
 	/*
 	 * Wait up to 15 seconds for the other cpus to respond to the NMI.
@@ -227,5 +234,6 @@ static void nmi_dump(void)
 	 * Save the nmi cpu registers for all cpu in the eframe format.
 	 */
 	nmi_eframes_save();
+	printk_trigger_flush();
 	LOCAL_HUB_S(NI_PORT_RESET, NPR_PORTRESET | NPR_LOCALRESET);
 }
-- 
2.47.3

Re: [PATCH v2] MIPS: SGI-IP27: print the NMI dump on an nbcon console

[John Ogness]

On 2026-10-01, Imre Kaloz <kaloz@kernel.org> wrote:
> Since the 8250 console became nbcon, printk() in nmi_dump() only queues
> records for a printer thread that never runs, as no CPU leaves the NMI
> handler. Print from an emergency section and flush pending records
> before the hub reset.
>
> Fixes: d3539347022a ("serial: 8250: Switch to nbcon console, take 2")
> Signed-off-by: Imre Kaloz <kaloz@kernel.org>

Reviewed-by: John Ogness <john.ogness@linutronix.de>

Re: [PATCH v2] MIPS: SGI-IP27: print the NMI dump on an nbcon console

[Petr Mladek]

On Thu 2026-10-01 21:19:38, Imre Kaloz wrote:
> Since the 8250 console became nbcon, printk() in nmi_dump() only queues
> records for a printer thread that never runs, as no CPU leaves the NMI
> handler. Print from an emergency section and flush pending records
> before the hub reset.
> 
> Fixes: d3539347022a ("serial: 8250: Switch to nbcon console, take 2")
> Signed-off-by: Imre Kaloz <kaloz@kernel.org>

Looks good to me:

Reviewed-by: Petr Mladek <pmladek@suse.com>

I assume that it would go via mips or drivers tree.
Please, let me know if you would prefer to push it via printk tree.

Best Regards,
Petr

Re: [PATCH v2] MIPS: SGI-IP27: print the NMI dump on an nbcon console

[Greg Kroah-Hartman]

On Fri, Oct 02, 2026 at 09:27:36AM +0200, Petr Mladek wrote:
> On Thu 2026-10-01 21:19:38, Imre Kaloz wrote:
> > Since the 8250 console became nbcon, printk() in nmi_dump() only queues
> > records for a printer thread that never runs, as no CPU leaves the NMI
> > handler. Print from an emergency section and flush pending records
> > before the hub reset.
> > 
> > Fixes: d3539347022a ("serial: 8250: Switch to nbcon console, take 2")
> > Signed-off-by: Imre Kaloz <kaloz@kernel.org>
> 
> Looks good to me:
> 
> Reviewed-by: Petr Mladek <pmladek@suse.com>
> 
> I assume that it would go via mips or drivers tree.
> Please, let me know if you would prefer to push it via printk tree.

Should probably go through a mips tree to resolve the conflicts.

thanks,

greg k-h

Re: [PATCH v2] MIPS: SGI-IP27: print the NMI dump on an nbcon console

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] printk: NMI dump output lost due to nbcon timeout if console is in unsafe state
--

commit f9358977a85eff3b02febdb716b027b3e2f5107f
Author: Imre Kaloz <kaloz@kernel.org>

MIPS: SGI-IP27: print the NMI dump on an nbcon console

Since the 8250 console became nbcon, printk() in nmi_dump() only queues
records for a printer thread that never runs, as no CPU leaves the NMI
handler. Print from an emergency section and flush pending records
before the hub reset.

> diff --git a/arch/mips/sgi-ip27/ip27-nmi.c b/arch/mips/sgi-ip27/ip27-nmi.c
> index fc2816398d0cf..c502982621e6b 100644
> --- a/arch/mips/sgi-ip27/ip27-nmi.c
> +++ b/arch/mips/sgi-ip27/ip27-nmi.c
> @@ -183,6 +184,12 @@ static void nmi_dump(void)
>  	 */
>  	arch_spin_lock(&nmi_lock);

[Severity: High]
If another CPU was interrupted while holding an nbcon console in an unsafe
state, will it be trapped here spinning indefinitely on nmi_lock?

If so, it would never be able to release the console.

>  
> +	/*
> +	 * No CPU leaves the NMI handler before the hub reset below, so an
> +	 * nbcon console's printer thread would never print the dump.
> +	 */
> +	nbcon_cpu_emergency_enter();

[Severity: High]
Does entering EMERGENCY priority here instead of PANIC prevent a hostile
takeover of the console?

Hostile unsafe takeovers require panic_on_this_cpu() to be true via
nbcon_allow_unsafe_takeover().

Since panic() is not called during this NMI dump sequence, it appears this
would fall short of allowing a takeover if the console is locked.

> +
>  #ifdef REAL_NMI_SIGNAL
>  	/*

[ ... ]

> @@ -227,5 +234,6 @@ static void nmi_dump(void)
>  	 * Save the nmi cpu registers for all cpu in the eframe format.
>  	 */
>  	nmi_eframes_save();
> +	printk_trigger_flush();

[Severity: High]
Will this flush completely suppress the dump output if the console was held
by one of the trapped CPUs?

If the system attempts a handover here, it will wait 2000us and time out
because the other CPU is trapped on nmi_lock.

Following the timeout, nbcon_context_try_acquire_hostile() will fail with
-EPERM because PANIC priority was not established.

Could this cause the flush to fail entirely, silently triggering a hardware
reset via LOCAL_HUB_S() without outputting any diagnostic information?

>  	LOCAL_HUB_S(NI_PORT_RESET, NPR_PORTRESET | NPR_LOCALRESET);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261001191938.3256-1-kaloz@kernel.org?part=1