Re: [PATCH] x86/nmi: Ignore negative NMI handler durations

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Oct 27, 2026 at 12:25:20PM -0400, Rik van Riel wrote:
> On Tue, 2026-10-27 at 03:43 -0700, Breno Leitao wrote:
> > I am seeing NMI handlers in the Meta fleet reported as running for
> > about 584 years. Over 30 days, 11 AMD and Intel machines logged 637
> > such lines, for example:
> > 
> >   AMD EPYC 9D25 (family 0x1a, model 0x11, stepping 0x0):
> >   [ 1650.616627] INFO: NMI handler
> > (nmi_cpu_backtrace_handler.llvm.9643156322683129580) took too long to
> > run: 18446744073709.551 msecs
> > 
> >   Intel Xeon Platinum 8321HC (family 0x6, model 0x55, stepping 0xb):
> >   [360448.230129] INFO: NMI handler (perf_event_nmi_handler) took too
> > long to run: 18446744071018.936 msecs
> > 
> >   Intel Xeon D-2191A (family 0x6, model 0x55, stepping 0x4):
> >   [81787.188959] INFO: NMI handler (ghes_notify_nmi) took too long to
> > run: 18446744073709.545 msecs
> > 
> > nmi_handle() times each handler with two sched_clock() reads. When
> > the
> > second read is lower than the first, the u64 subtraction wraps, and
> > nmi_check_duration() treats the result as a duration. In the three
> > examples, the clock went back by less than 1 us, by 2.7 s and by
> > about
> > 6 us.
> > 
> The comment above ktime_get_mono_fast_ns() makes
> me wonder whether for time deltas we should read
> raw TSC values, and calculate the time delta between
> them afterward.
> 

This is sched_clock(); that *never* changes slope -- after boot, on sane
hardware.