Re: [PATCH x86/nmi 2/2] x86/nmi: Print reasons why backtrace NMIs are ignored

From: Ingo Molnar
Date: Thu Jan 05 2023 - 05:42:32 EST



* Paul E. McKenney <paulmck@xxxxxxxxxx> wrote:

> +#ifdef CONFIG_NMI_CHECK_CPU
> +
> +static char *nmi_check_stall_msg[] = {
> +/* */
> +/* +--------- nsp->idt_seq_snap & 0x1: CPU is in NMI handler. */
> +/* | +------ cpu_is_offline(cpu) */
> +/* | | +--- nsp->idt_calls_snap != atomic_long_read(&nsp->idt_calls): */
> +/* | | | NMI handler has been invoked. */
> +/* | | | */
> +/* V V V */
> +/* 0 0 0 */ "NMIs are not reaching exc_nmi handler",
> +/* 0 0 1 */ "exc_nmi handler is ignoring NMIs",
> +/* 0 1 0 */ "CPU is offline and NMIs are not reaching exc_nmi handler",
> +/* 0 1 1 */ "CPU is offline and exc_nmi handler is legitimately ignoring NMIs",
> +/* 1 0 0 */ "CPU is in exc_nmi handler and no further NMIs are reaching handler",
> +/* 1 0 1 */ "CPU is in exc_nmi handler which is legitimately ignoring NMIs",
> +/* 1 1 0 */ "CPU is offline in exc_nmi handler and no further NMIs are reaching exc_nmi handler",
> +/* 1 1 1 */ "CPU is offline in exc_nmi handler which is legitimately ignoring NMIs",

That kind of disambiguation of why a CPU is stuck looks really useful:

Reviewed-by: Ingo Molnar <mingo@xxxxxxxxxx>

One small suggestion would be to do this in the messages:

s/exc_nmi handler
/exc_nmi() handler

... to make it clear that it's a regular kernel function [well, hw entry
handler], not a function pointer or some other indirection? No strong
feelings though.

Thanks,

Ingo