Re: [PATCH] clockevents: Prevent timer interrupt starvation

[Calvin Owens]

On Friday 04/03 at 16:41 +0200, Thomas Gleixner wrote:
> On Thu, Apr 02 2026 at 22:11, Calvin Owens wrote:
> > On Thursday 04/02 at 19:07 +0200, Thomas Gleixner wrote:
> >> Calvin reported an odd NMI watchdog lockup which claims that the CPU locked
> >> up in user space. He provided a reproducer, which set's up a timerfd based
> >> timer and then rearms it in a loop with an absolute expiry time of 1ns.
> >> 
> >> As the expiry time is in the past, the timer ends up as the first expiring
> >> timer in the per CPU hrtimer base and the clockevent device is programmed
> >> with the minimum delta value. If the machine is fast enough, this ends up
> >> in a endless loop of programming the delta value to the minimum value
> >> defined by the clock event device, before the timer interrupt can fire,
> >> which starves the interrupt and consequently triggers the lockup detector
> >> because the hrtimer callback of the lockup mechanism is never invoked.
> >> 
> >> As a first step to prevent this, avoid reprogramming the clock event device
> >> when:
> >>      - a forced minimum delta event is pending
> >>      - the new expiry delta is less then or equal to the minimum delta
> >> 
> >> Thanks to Calvin for providing the reproducer and to Borislav for testing
> >> and providing data from his Zen5 machine.
> >> 
> >> The problem is not limited to Zen5, but depending on the underlying
> >> clock event device (e.g. TSC deadline timer on Intel) and the CPU speed
> >> not necessarily observable.
> >> 
> >> This change serves only as the last resort and further changes will be made
> >> to prevent this scenario earlier in the call chain.
> >> 
> >> Reported-by: Calvin Owens <calvin@xxxxxxxxxx>
> >> Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxx>
> >> ---
> >> P.S: I'm working on the other changes, but wanted to get this out ASAP
> >>      for testing.
> >
> > Unfortunately the AMD boxes won't boot with this: one gives me no
> > video console output, the other gets to userspace but hangs trying to
> > mount the rootfs and then prints hard lockup traces with idle stacks.
> >
> > Sorry not to have more info yet, I'll have time tomorrow to sit down and
> > get more data for you. If there's anything specific that you'd like me
> > grab just let me know.
> 
> I'm an idiot. When I polished the patch up, I dropped the hunks which
> clear the flag in the interrupt handler and tired brain did not notice
> despite checking five times in a row. Updated version below.

That did it, both AMD machines survive the reproducer and are well
behaved afterwards.

If you like:

Tested-By: Calvin Owens <calvin@xxxxxxxxxx>

Thanks,
Calvin