Re: [PATCH v2] x86/nmi: Enable panic() when NMI handler runs too long

[Paul E. McKenney]

On Mon, Oct 19, 2026 at 09:52:47PM -0700, Borislav Petkov wrote:
> On Mon, Oct 19, 2026 at 01:44:30PM -0700, Paul E. McKenney wrote:
> > Firmware, device-driver, and configuration issues can result in
> > long-running NMI handlers, for example, nmi_cpu_backtrace_handler()
> > running for more than two seconds, and with no console issues.  In this
> > case, this is not the fault of nmi_cpu_backtrace_handler(), but it is
> > the first symptom of the underlying problem.  These NMI handlers result
> > in various other problems, including CSD-lock warnings, clocksource
> > watchdog false positives, scheduler frequency invariance wobbliness,
> > systemd excessive-CPU complaints, and even the occasional RCU CPU
> > stall warning.  Eventually, the automation will take the system out of
> > service, but with quite a bit of noise obscuring the underlying issue,
> > and thus confusing both automation and human beings.
> > 
> > Therefore, provide a toolong_nmi_panic __setup() parameter that makes
> > nmi_check_duration() invoke nmi_panic() if the just-completed NMI handler
> > ran for more than the specified number of milliseconds.  This parameter
> > defaults to zero, which disables the nmi_panic().  As in, by default
> > you get the same behavior that you get today.
> > 
> > [ paulmck: Apply kernel test robot feedback, add documentation. ]
> > 
> > Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxx>
> > Cc: Thomas Gleixner <tglx@xxxxxxxxxx>
> > Cc: Ingo Molnar <mingo@xxxxxxxxxx>
> > Cc: Borislav Petkov <bp@xxxxxxxxx>
> > Cc: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
> > Cc: "H. Peter Anvin" <hpa@xxxxxxxxx>
> > Cc: <x86@xxxxxxxxxx>
> > 
> > ---
> >  Documentation/admin-guide/kernel-parameters.txt |    6 ++++++
> >  arch/x86/kernel/nmi.c                           |   21 +++++++++++++++++++--
> >  2 files changed, 25 insertions(+), 2 deletions(-)
> > 
> > Changes since v1:
> > 
> > o	Add documentation of new toolong_nmi_panic kernel boot parameter.
> > 
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > index 68647ff4bdd24..e7dbd5bf48fc9 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -7642,6 +7642,12 @@ Kernel parameters
> >  			Format: {ipi}
> >  			ipi: switch to IPI-based TLB flushing
> >  
> > +	toolong_nmi_panic= [X86]
> > +			Cause a panic upon return from an NMI handler
> > +			that took longer than the specified number
> > +			of milliseconds.  The default value of zero
> > +			suppresses these panics.
> 
> Cause a panic after an NMI?!

When the NMI handler runs for more than ten seconds, life is hard anyway.
And no, these were not bugs in the several affected NMI handlers themselves.

> Oh boy, is this trying to solve a Meta fleet problem and you're thinking, why
> not upstream it too?
> 
> Because I fail to use the usefulness of this...

I might be wrong, but I doubt that Meta's fleet is the only place where
such bugs appear.  ;-)

							Thanx, Paul