Re: [patch V2 01/11] hrtimer: Provide hrtimer_start_range_ns_user()

[Frederic Weisbecker]

Le Wed, Apr 08, 2026 at 01:53:46PM +0200, Thomas Gleixner a écrit :
> 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.
> 
> The clockevents code already has a last resort mechanism to prevent that,
> but it's sensible to catch such issues before trying to reprogram the clock
> event device.
> 
> Provide a variant of hrtimer_start_range_ns(), which sanity checks the
> timer after queueing it. It does not so before because the timer might be
> armed and therefore needs to be dequeued. also we optimize for the latest
> possible point to check, so that the clock event prevention is avoided as
> much as possible.
> 
> If the timer is already expired _before_ the clock event is reprogrammed,
> remove the timer from the queue and signal to the caller that the operation
> failed by returning false.
> 
> That allows the caller to take immediate action without going through the
> loops and hoops of the hrtimer interrupt.
> 
> The queueing code can't invoke the timer callback as the caller might hold
> a lock which is taken in the callback.
> 
> Add a tracepoint which allows to analyze the expired at start situation.
> 
> Reported-by: Calvin Owens <calvin@xxxxxxxxxx>
> Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxx>
> Cc: Anna-Maria Behnsen <anna-maria@xxxxxxxxxxxxx>
> Cc: Frederic Weisbecker <frederic@xxxxxxxxxx>

Reviewed-by: Frederic Weisbecker <frederic@xxxxxxxxxx>

-- 
Frederic Weisbecker
SUSE Labs