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

[Dave Hansen <dave.hansen@intel.com>]

On 10/20/26 09:15, Paul E. McKenney wrote:
>>> +	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.  😉

Yeah, I once upon a time had a bunch of problems with NMIs taking
forever to run. In my case, it was some actually wonky firmware, but
differentiating the broken firmware from NMI handlers just being slow is
what motivated the existing "took too long to run" message next to which
you added the nmi_panic().

That said, I'd much prefer something more generic than something
NMI-specific.

Would the systems that set toolong_nmi_panic=1 also set panic_on_warn=1?
Are there any other "extra" panics that these systems also find useful?

I'm kinda curious if, for instance:

	hung_task_panic=1
or
	softlockup_panic=1

would also panic() these systems.