lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230105192430.GJ4028633@paulmck-ThinkPad-P17-Gen-1>
Date:   Thu, 5 Jan 2023 11:24:30 -0800
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     linux-kernel@...r.kernel.org, kernel-team@...a.com,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org
Subject: Re: [PATCH x86/nmi 2/2] x86/nmi: Print reasons why backtrace NMIs
 are ignored

On Thu, Jan 05, 2023 at 11:40:30AM +0100, Ingo Molnar wrote:
> 
> * Paul E. McKenney <paulmck@...nel.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@...nel.org>

Glad you like it and thank you!  I will apply this on the next rebase.

> 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.

Will do!  I would balk at "DEFINE_IDTENTRY_RAW(exc_nmi)", though.  ;-)

							Thanx, Paul

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ