Re: [PATCH v2] stop_machine: Defer legacy console flushes while a CPU runs a stopper callback

[John Ogness <john.ogness@linutronix.de>]

On 2026-09-10, Aditya Chillara <aditya.chillara@oss.qualcomm.com> wrote:
> The cpu stopper thread runs above every other scheduling class, so while a
> stopper callback executes, nothing else on that CPU is scheduled. If such a
> callback emits a normal-priority printk(), the legacy console path can
> synchronously flush the pending console backlog. On systems with a slow
> UART and a large backlog, this holds the CPU long enough to starve RT
> kthreads such as the watchdog pet, and for multi_cpu_stop() prevents the
> CPU from advancing the state machine while the other CPUs wait. The
> resulting delay can prevent watchdog servicing long enough to trigger a
> watchdog bark or bite.
>
> The same can happen from an interrupt taken during the callback:
> multi_cpu_stop() keeps interrupts enabled during MULTI_STOP_PREPARE, and a
> printk() may be emitted from a softirq run on irq exit.
>
> Run CPU stopper callbacks in printk-deferred context to prevent legacy
> console flushes while they execute.
>
> Signed-off-by: Aditya Chillara <aditya.chillara@oss.qualcomm.com>

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

> Heavy SELinux denial logging had built up a large backlog on the
> console. One CPU took an interrupt while spinning in MULTI_STOP_PREPARE.
> Handling it eventually led to a printk(), and because the console was a
> legacy console, that printk() synchronously drained the whole backlog
> over the slow UART.

Note that with the new nbcon consoles, this will still happen if the CPU
is in an emergency state (WARN/panic), but that is the intended
behavior.

John