Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Sender: Ingo Molnar <mingo.kernel.org@gmail.com>
Date:   Thu, 5 Jan 2023 11:40:30 +0100
From:   Ingo Molnar <mingo@kernel.org>
To:     "Paul E. McKenney" <paulmck@kernel.org>
Cc:     linux-kernel@vger.kernel.org, kernel-team@meta.com,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "H. Peter Anvin" <hpa@zytor.com>, x86@kernel.org
Subject: Re: [PATCH x86/nmi 2/2] x86/nmi: Print reasons why backtrace NMIs
 are ignored
Message-ID: <Y7apHi9A0i63X4Me@gmail.com>
References: <20230105011537.1774941-1-paulmck@kernel.org>
 <20230105011537.1774941-2-paulmck@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230105011537.1774941-2-paulmck@kernel.org>
Precedence: bulk


* Paul E. McKenney <paulmck@kernel.org> 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@kernel.org>

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