hrtimers: Prevent hrtimer interrupt starvation

kernel/time/clockevents.c +6 -7

@@ -324,16 +324,23 @@ int clockevents_program_event(struct clo
 		return dev->set_next_ktime(expires, dev);
 
 	delta = ktime_to_ns(ktime_sub(expires, ktime_get()));
-	if (delta <= 0)
-		return force ? clockevents_program_min_delta(dev) : -ETIME;
 
-	delta = min(delta, (int64_t) dev->max_delta_ns);
-	delta = max(delta, (int64_t) dev->min_delta_ns);
 
-	clc = ((unsigned long long) delta * dev->mult) >> dev->shift;
-	rc = dev->set_next_event((unsigned long) clc, dev);
 
-	return (rc && force) ? clockevents_program_min_delta(dev) : rc;
 }
 

@@ -324,16 +324,23 @@ int clockevents_program_event(struct clo
 		return dev->set_next_ktime(expires, dev);
 
 	delta = ktime_to_ns(ktime_sub(expires, ktime_get()));
 
+	if (delta > (int64_t)dev->min_delta_ns) {
+		delta = min(delta, (int64_t) dev->max_delta_ns);
+		clc = ((unsigned long long) delta * dev->mult) >> dev->shift;
+		if (!dev->set_next_event((unsigned long) clc, dev))
+			return 0;
+	}
 

Quoted 12 lines · Thomas Gleixner

kernel/time/clockevents.c +6 -0

@@ -324,16 +324,23 @@ int clockevents_program_event(struct clo
 		return dev->set_next_ktime(expires, dev);
 
 	delta = ktime_to_ns(ktime_sub(expires, ktime_get()));
 
+	if (delta > (int64_t)dev->min_delta_ns) {
+		delta = min(delta, (int64_t) dev->max_delta_ns);
+		clc = ((unsigned long long) delta * dev->mult) >> dev->shift;
+		if (!dev->set_next_event((unsigned long) clc, dev))
+			return 0;
+	}
 

kernel/time/clockevents.c int clockevents_program_event(struct clo · line 344

Quoted 10 lines

kernel/time/clockevents.c +8 -0

+	if (dev->next_event_forced)
+		return 0;
 
+	if (dev->set_next_event(dev->min_delta_ticks, dev)) {
+		if (!force || clockevents_program_min_delta(dev))
+			return -ETIME;
+	}
+	dev->next_event_forced = 1;
+	return 0;
 }

Looking at the implementation of clockevents_program_min_delta() doing that dev->set_next_event(dev->min_delta_ticks,) right before it seems a bit daft.

But yes, this is effectively also what the old code did.

The only thing that seems to be different, is that the old code would return the ->set_next_event() error code, rather than 0 in the !force case.

Quoted 28 lines · Peter Zijlstra

Quoted 12 lines · Thomas Gleixner

kernel/time/clockevents.c +6 -0

@@ -324,16 +324,23 @@ int clockevents_program_event(struct clo
 		return dev->set_next_ktime(expires, dev);
 
 	delta = ktime_to_ns(ktime_sub(expires, ktime_get()));
 
+	if (delta > (int64_t)dev->min_delta_ns) {
+		delta = min(delta, (int64_t) dev->max_delta_ns);
+		clc = ((unsigned long long) delta * dev->mult) >> dev->shift;
+		if (!dev->set_next_event((unsigned long) clc, dev))
+			return 0;
+	}
 

kernel/time/clockevents.c int clockevents_program_event(struct clo · line 344

Quoted 10 lines

kernel/time/clockevents.c +8 -0

+	if (dev->next_event_forced)
+		return 0;
 
+	if (dev->set_next_event(dev->min_delta_ticks, dev)) {
+		if (!force || clockevents_program_min_delta(dev))
+			return -ETIME;
+	}
+	dev->next_event_forced = 1;
+	return 0;
 }

Looking at the implementation of clockevents_program_min_delta() doing that dev->set_next_event(dev->min_delta_ticks,) right before it seems a bit daft.

Quoted 1 line

But yes, this is effectively also what the old code did.

yes. I looked at that and didn't come up with a good plan.

Quoted 3 lines

The only thing that seems to be different, is that the old code would return the ->set_next_event() error code, rather than 0 in the !force case.

You mean when dev->next_event_forced is set and the set_event() callback above failed?

Quoted 6 lines · Thomas Gleixner

Quoted 3 lines

The only thing that seems to be different, is that the old code would return the ->set_next_event() error code, rather than 0 in the !force case.

You mean when dev->next_event_forced is set and the set_event() callback above failed?

next_event_foced = 0;
force = 0;

Then the old code would return rc (return value of ->set_next_event), while the new code will return -ETIME.

(not 0 like I said).

I suppose ->set_next_event() will only ever fail with -ETIME?

From: Thomas Gleixner <[email protected]>

Calvin reported an odd NMI watchdog lockup which claims that the CPU locked up in user space. He provided a reproducer, which sets 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 as far as possible.

Fixes d316c57ff6bf ("[PATCH] clockevents: add core functionality")

Reported-by Calvin Owens <[email protected]>

Signed-off-by Thomas Gleixner <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Anna-Maria Behnsen <[email protected]>

Cc Frederic Weisbecker <[email protected]>

Cc Ingo Molnar <[email protected]>

Link https://lore.kernel.org/lkml/[email protected]/ open here

---
V2: Simplified the clockevents code - Peter

Quoted 37 lines · Thomas Gleixner

From: Thomas Gleixner <[email protected]>

Calvin reported an odd NMI watchdog lockup which claims that the CPU locked up in user space. He provided a reproducer, which sets 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 as far as possible.

Fixes d316c57ff6bf ("[PATCH] clockevents: add core functionality")

Reported-by Calvin Owens <[email protected]>

Signed-off-by Thomas Gleixner <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Anna-Maria Behnsen <[email protected]>

Cc Frederic Weisbecker <[email protected]>

Cc Ingo Molnar <[email protected]>

Link https://lore.kernel.org/lkml/[email protected]/ open here

Quoted 2 lines

---
V2: Simplified the clockevents code - Peter

Isn't it possible to rely on dev->next_event instead? In the above scenario, subsequent 0 delta would not reprogram if dev->next_event is already below the new call to ktime_get() ?

On Tue, Apr 07 2026 at 16:00, Frederic Weisbecker wrote:
As I had to introduce the flag and prevent the other scenraio I just consolidated everything into one code path.

From: Thomas Gleixner <[email protected]>

Calvin reported an odd NMI watchdog lockup which claims that the CPU locked up in user space. He provided a reproducer, which sets 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 as far as possible.

From: Thomas Gleixner <[email protected]>

Calvin reported an odd NMI watchdog lockup which claims that the CPU locked up in user space. He provided a reproducer, which sets 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

Hi Thomas,

Quoted 14 lines · Thomas Gleixner

From: Thomas Gleixner <[email protected]>

Calvin reported an odd NMI watchdog lockup which claims that the CPU locked up in user space. He provided a reproducer, which sets 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.

Quoted 4 lines

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

with this patch now in the tip tree my QEMU/virtme-ng based machine fails to boot. The startup seems to freeze in:
start_kernel() -> rest_init() -> schedule_preempt_disabled() -> schedule()

CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST_IDLE=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_HZ=1000

CPU: i5-1135G7
clock event device: lapic-deadline

The clockevent device is still reprogrammed each millisecond, presumably for the tick.

(...)

From: Thomas Gleixner <[email protected]>

Calvin reported an odd NMI watchdog lockup which claims that the CPU locked up in user space. He provided a reproducer, which sets 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 as far as possible.

Fixes d316c57ff6bf ("[PATCH] clockevents: add core functionality")

Reported-by Calvin Owens <[email protected]>

Signed-off-by Thomas Gleixner <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Anna-Maria Behnsen <[email protected]>

Cc Frederic Weisbecker <[email protected]>

Cc Ingo Molnar <[email protected]>

Link https://lore.kernel.org/lkml/[email protected]/ open here

From: Thomas Gleixner <[email protected]>

Calvin reported an odd NMI watchdog lockup which claims that the CPU locked up in user space. He provided a reproducer, which sets 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 as far as possible.

Fixes d316c57ff6bf ("[PATCH] clockevents: add core functionality")

Reported-by Calvin Owens <[email protected]>

Signed-off-by Thomas Gleixner <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Anna-Maria Behnsen <[email protected]>

Cc Frederic Weisbecker <[email protected]>

Cc Ingo Molnar <[email protected]>

Link https://lore.kernel.org/lkml/[email protected]/ open here

Quoted 1 line

Link https://lore.kernel.org/lkml/[email protected]/ open here

This change in -next as commit 1c2eabb8805d ("clockevents: Prevent timer interrupt starvation") appears to make one of my test machines consistently lock up on boot (at least I never get to userspace). Most of the time I get stall messages such as

Quoted 6 lines · Nathan Chancellor

Quoted 1 line

Link https://lore.kernel.org/lkml/[email protected]/ open here

This change in -next as commit 1c2eabb8805d ("clockevents: Prevent timer interrupt starvation") appears to make one of my test machines consistently lock up on boot (at least I never get to userspace). Most of the time I get stall messages such as

Can you please retest the changes I just pushed out into:

git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/urgent

namely: d6e152d905bd ("clockevents: Prevent timer interrupt starvation")

From: Thomas Gleixner <[email protected]>

Calvin reported an odd NMI watchdog lockup which claims that the CPU locked up in user space. He provided a reproducer, which sets 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 as far as possible.

Fixes d316c57ff6bf ("[PATCH] clockevents: add core functionality")

Reported-by Calvin Owens <[email protected]>

Signed-off-by Thomas Gleixner <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Anna-Maria Behnsen <[email protected]>

Cc Frederic Weisbecker <[email protected]>

Cc Ingo Molnar <[email protected]>

Link https://lore.kernel.org/lkml/[email protected]/ open here

---
V2: Simplified the clockevents code - Peter

---
  include/linux/clockchips.h |    2 ++
  kernel/time/clockevents.c  |   23 +++++++++++++++--------
  kernel/time/hrtimer.c      |    1 +
  kernel/time/tick-common.c  |    1 +
  kernel/time/tick-sched.c   |    1 +
  5 files changed, 20 insertions(+), 8 deletions(-)

include/linux/clockchips.h +2 -0

@@ -80,6 +80,7 @@ enum clock_event_state {
   * @shift:		nanoseconds to cycles divisor (power of two)
   * @state_use_accessors:current state of the device, assigned by the core code
   * @features:		features
+ * @next_event_forced:	True if the last programming was a forced event
   * @retries:		number of forced programming retries
   * @set_state_periodic:	switch state to periodic
   * @set_state_oneshot:	switch state to oneshot

@@ -108,6 +109,7 @@ struct clock_event_device {
  	u32			shift;
  	enum clock_event_state	state_use_accessors;
  	unsigned int		features;
+	unsigned int		next_event_forced;
  	unsigned long		retries;
 
  	int			(*set_state_periodic)(struct clock_event_device *);

kernel/time/clockevents.c +15 -8

@@ -172,6 +172,7 @@ void clockevents_shutdown(struct clock_e
  {
  	clockevents_switch_state(dev, CLOCK_EVT_STATE_SHUTDOWN);
  	dev->next_event = KTIME_MAX;
+	dev->next_event_forced = 0;
  }
 
  /**

@@ -305,7 +306,6 @@ int clockevents_program_event(struct clo
  {
  	unsigned long long clc;
  	int64_t delta;
-	int rc;
 
  	if (WARN_ON_ONCE(expires < 0))
  		return -ETIME;

@@ -324,16 +324,23 @@ int clockevents_program_event(struct clo
  		return dev->set_next_ktime(expires, dev);
 
  	delta = ktime_to_ns(ktime_sub(expires, ktime_get()));
-	if (delta <= 0)
-		return force ? clockevents_program_min_delta(dev) : -ETIME;
 
-	delta = min(delta, (int64_t) dev->max_delta_ns);
-	delta = max(delta, (int64_t) dev->min_delta_ns);
+	if (delta > (int64_t)dev->min_delta_ns) {
+		delta = min(delta, (int64_t) dev->max_delta_ns);
+		clc = ((unsigned long long) delta * dev->mult) >> dev->shift;
+		if (!dev->set_next_event((unsigned long) clc, dev))
+			return 0;
+	}
 
-	clc = ((unsigned long long) delta * dev->mult) >> dev->shift;
-	rc = dev->set_next_event((unsigned long) clc, dev);
+	if (dev->next_event_forced)
+		return 0;
 
-	return (rc && force) ? clockevents_program_min_delta(dev) : rc;
+	if (dev->set_next_event(dev->min_delta_ticks, dev)) {
+		if (!force || clockevents_program_min_delta(dev))
+			return -ETIME;
+	}
+	dev->next_event_forced = 1;
+	return 0;
  }
 
  /*

kernel/time/hrtimer.c +1 -0

@@ -1888,6 +1888,7 @@ void hrtimer_interrupt(struct clock_even
  	BUG_ON(!cpu_base->hres_active);
  	cpu_base->nr_events++;
  	dev->next_event = KTIME_MAX;
+	dev->next_event_forced = 0;
 
  	raw_spin_lock_irqsave(&cpu_base->lock, flags);
  	entry_time = now = hrtimer_update_base(cpu_base);

kernel/time/tick-common.c +1 -0

@@ -110,6 +110,7 @@ void tick_handle_periodic(struct clock_e
  	int cpu = smp_processor_id();
  	ktime_t next = dev->next_event;
 
+	dev->next_event_forced = 0;
  	tick_periodic(cpu);
 
  	/*

Hello.

Sorry, but this patch as of 7.0 introduced *severe* periodic lockups on my Ryzen 7700X machine.
I see such messages in the log:

clocksource: Long readout interval, skipping watchdog check: cs_nsec:
2897344852 wd_nsec: 2897356996

Reverting d6e152d905bdb1f32f9d99775e2f453350399a6a for mainline fixes the issue for me.

Quoted 7 lines · Hanabishi

Hello.

Sorry, but this patch as of 7.0 introduced *severe* periodic lockups on my Ryzen 7700X machine.
I see such messages in the log:

Quoted 6 lines

clocksource: Long readout interval, skipping watchdog check: cs_nsec:
2897344852 wd_nsec: 2897356996

Reverting d6e152d905bdb1f32f9d99775e2f453350399a6a for mainline fixes the issue for me.

Hi maintainers,

several users from CachyOS has reported this regression as well. We landed on the same bisection. One of the users that could reproduce this reliably reproduced this just by watching a YouTube video in a browser, and observed freezes and stutters when interacting with the system.

Quoted 17 lines · Eric Naim

Quoted 7 lines · Hanabishi

Hello.

Sorry, but this patch as of 7.0 introduced *severe* periodic lockups on my Ryzen 7700X machine.
I see such messages in the log:

Quoted 6 lines

clocksource: Long readout interval, skipping watchdog check: cs_nsec:
2897344852 wd_nsec: 2897356996

Reverting d6e152d905bdb1f32f9d99775e2f453350399a6a for mainline fixes the issue for me.

Hi maintainers,

Quoted 4 lines

several users from CachyOS has reported this regression as well. We landed on the same bisection. One of the users that could reproduce this reliably reproduced this just by watching a YouTube video in a browser, and observed freezes and stutters when interacting with the system.

Huh, I can't reproduce this at all across 10+ machines. Can you share the Kconfig you're seeing this on?

Thanks,
Calvin

Quoted 7 lines · Hanabishi

Hello.

Sorry, but this patch as of 7.0 introduced *severe* periodic lockups on my Ryzen 7700X machine.
I see such messages in the log:

Quoted 6 lines

clocksource: Long readout interval, skipping watchdog check: cs_nsec:
2897344852 wd_nsec: 2897356996

Reverting d6e152d905bdb1f32f9d99775e2f453350399a6a for mainline fixes the issue for me.

Hi maintainers,

several users from CachyOS has reported this regression as well. We landed on the same bisection. One of the users that could reproduce this reliably reproduced this just by watching a YouTube video in a browser, and observed freezes and stutters when interacting with the system.

I had an LLM generate a fix (patch attached), and it fixed the regression for that user. Full disclosure: it is written completely by AI, and I am also not familiar with this subsystem. I just hope that this patch can be helpful in fixing the regression.

Please don't hesitate to tell me off if utilizing AI in this way is not helpful, so I can keep this in mind for future contributions.

Signature · 2 lines

Regards,
  Eric

kernel/time/clockevents.c +3 -1

index 38570998a19b..37b10045572e 100644
@@ -332,8 +332,10 @@ int clockevents_program_event(struct clock_event_device *dev, ktime_t expires,
 	if (delta > (int64_t)dev->min_delta_ns) {
 		delta = min(delta, (int64_t) dev->max_delta_ns);
 		clc = ((unsigned long long) delta * dev->mult) >> dev->shift;
-		if (!dev->set_next_event((unsigned long) clc, dev))
+		if (!dev->set_next_event((unsigned long) clc, dev)) {
+			dev->next_event_forced = 0;
 			return 0;
+		}
 	}
 
 	if (dev->next_event_forced)

kernel/time/tick-oneshot.c +1 -0

index 7472597f3225..bf411472d4f7 100644
@@ -34,6 +34,7 @@ int tick_program_event(ktime_t expires, int force)
 		 */
 		clockevents_switch_state(dev, CLOCK_EVT_STATE_ONESHOT_STOPPED);
 		dev->next_event = KTIME_MAX;
+		dev->next_event_forced = 0;
 		return 0;
 	}
 

Can you try the following?

kernel/time/clockevents.c +5 -2

index b4d730604972..5c6dfd6bed28 100644
@@ -100,6 +100,7 @@ static int __clockevents_switch_state(struct clock_event_device *dev,
  		/* The clockevent device is getting replaced. Shut it down. */
 
  	case CLOCK_EVT_STATE_SHUTDOWN:
+		dev->next_event_forced = 0;
  		if (dev->set_state_shutdown)
  			return dev->set_state_shutdown(dev);
  		return 0;

@@ -127,10 +128,12 @@ static int __clockevents_switch_state(struct clock_event_device *dev,
  			      clockevent_get_state(dev)))
  			return -EINVAL;
 
-		if (dev->set_state_oneshot_stopped)
+		if (dev->set_state_oneshot_stopped) {
+			dev->next_event_forced = 0;
  			return dev->set_state_oneshot_stopped(dev);
-		else
+		} else {
  			return -ENOSYS;
+		}
 
  	default:
  		return -ENOSYS;

kernel/time/tick-broadcast.c +0 -0

index 7e57fa31ee26..115e0bf01276 100644

On 14/04/2026 18:04, Frederic Weisbecker wrote:

This patch doesn't help me unfortunately. Thanks.

The one below should cover all possible holes.

Thanks,

tglx
---

kernel/time/clockevents.c +6 -1

index b4d730604972..5e22697b098d 100644
@@ -94,6 +94,9 @@ static int __clockevents_switch_state(struct clock_event_device *dev,
  	if (dev->features & CLOCK_EVT_FEAT_DUMMY)
  		return 0;
 
+	/* On state transitions clear the forced flag unconditionally */
+	dev->next_event_forced = 0;
+
  	/* Transition with new state-specific callbacks */
  	switch (state) {
  	case CLOCK_EVT_STATE_DETACHED:

@@ -366,8 +369,10 @@ int clockevents_program_event(struct clock_event_device *dev, ktime_t expires, b
  	if (delta > (int64_t)dev->min_delta_ns) {
  		delta = min(delta, (int64_t) dev->max_delta_ns);
  		cycles = ((u64)delta * dev->mult) >> dev->shift;
-		if (!dev->set_next_event((unsigned long) cycles, dev))
+		if (!dev->set_next_event((unsigned long) cycles, dev)) {
+			dev->next_event_forced = 0;
  			return 0;
+		}
  	}
 
  	if (dev->next_event_forced)

kernel/time/tick-broadcast.c +0 -0

index 7e57fa31ee26..115e0bf01276 100644

Quoted 40 lines · Thomas Gleixner

The one below should cover all possible holes.

Thanks,

         tglx
---

kernel/time/clockevents.c +0 -0

index b4d730604972..5e22697b098d 100644
@@ -94,6 +94,9 @@ static int __clockevents_switch_state(struct
 clock_event_device *dev,
       if (dev->features & CLOCK_EVT_FEAT_DUMMY)
           return 0;

  +    /* On state transitions clear the forced flag unconditionally */ +    dev->next_event_forced = 0;
+
      /* Transition with new state-specific callbacks */ switch (state) {
      case CLOCK_EVT_STATE_DETACHED:

kernel/time/clockevents.c +3 -1

@@ -366,8 +369,10 @@ int clockevents_program_event(struct clock_event_device
 *dev, ktime_t expires, b
       if (delta > (int64_t)dev->min_delta_ns) {
           delta = min(delta, (int64_t) dev->max_delta_ns);
           cycles = ((u64)delta * dev->mult) >> dev->shift;
-        if (!dev->set_next_event((unsigned long) cycles, dev))
+        if (!dev->set_next_event((unsigned long) cycles, dev)) {
+            dev->next_event_forced = 0;
               return 0;
+        }
       }
         if (dev->next_event_forced)

kernel/time/tick-broadcast.c +0 -0

index 7e57fa31ee26..115e0bf01276 100644
@@ -108,6 +108,7 @@ static struct clock_event_device
 *tick_get_oneshot_wakeup_device(int cpu)
     static void tick_oneshot_wakeup_handler(struct clock_event_device *wd)
   {

kernel/time/tick-broadcast.c static struct clock_event_device *tick_get_oneshot_wakeup_device(int cpu) · line 114

Quoted 4 lines

kernel/time/tick-broadcast.c +1 -0

+    wd->next_event_forced = 0;
       /*
        * If we woke up early and the tick was reprogrammed in the
        * meantime then this may be spurious but harmless.

Ok, it does fix the problem! Thank you.
The patch itself does not apply cleanly for 7.0 though and I had to adapt it a bit.

The following commit has been merged into the timers/urgent branch of tip:

Commit-ID:     4096fd0e8eaea13ebe5206700b33f49635ae18e5
Gitweb:        https://git.kernel.org/tip/4096fd0e8eaea13ebe5206700b33f49635ae18e5
Author:        Thomas Gleixner <[email protected]>
AuthorDate:    Tue, 14 Apr 2026 22:55:01 +02:00
Committer:     Thomas Gleixner <[email protected]>
CommitterDate: Thu, 16 Apr 2026 21:22:04 +02:00

clockevents: Add missing resets of the next_event_forced flag

The prevention mechanism against timer interrupt starvation missed to reset the next_event_forced flag in a couple of places:

- When the clock event state changes. That can cause the flag to be stale over a shutdown/startup sequence

- When a non-forced event is armed, which then prevents rearming before that event. If that event is far out in the future this will cause missed timer interrupts.

- In the suspend wakeup handler.

That led to stalls which have been reported by several people.

Add the missing resets, which fixes the problems for the reporters.

Fixes d6e152d905bd ("clockevents: Prevent timer interrupt starvation")

Reported-by Hanabishi <[email protected]>

Reported-by Eric Naim <[email protected]>

Signed-off-by Thomas Gleixner <[email protected]>

Tested-by Hanabishi <[email protected]>

Tested-by Eric Naim <[email protected]>

Cc [email protected]

Closes https://lore.kernel.org/[email protected] open here

Link https://patch.msgid.link/87340xfeje.ffs@tglx open here

---
 kernel/time/clockevents.c    | 7 ++++++-
 kernel/time/tick-broadcast.c | 1 +
 2 files changed, 7 insertions(+), 1 deletion(-)

kernel/time/clockevents.c +6 -1

index b4d7306..5e22697 100644
@@ -94,6 +94,9 @@ static int __clockevents_switch_state(struct clock_event_device *dev,
 	if (dev->features & CLOCK_EVT_FEAT_DUMMY)
 		return 0;
 
+	/* On state transitions clear the forced flag unconditionally */
+	dev->next_event_forced = 0;
+
 	/* Transition with new state-specific callbacks */
 	switch (state) {
 	case CLOCK_EVT_STATE_DETACHED:

@@ -366,8 +369,10 @@ int clockevents_program_event(struct clock_event_device *dev, ktime_t expires, b
 	if (delta > (int64_t)dev->min_delta_ns) {
 		delta = min(delta, (int64_t) dev->max_delta_ns);
 		cycles = ((u64)delta * dev->mult) >> dev->shift;
-		if (!dev->set_next_event((unsigned long) cycles, dev))
+		if (!dev->set_next_event((unsigned long) cycles, dev)) {
+			dev->next_event_forced = 0;
 			return 0;
+		}
 	}
 
 	if (dev->next_event_forced)

kernel/time/tick-broadcast.c +1 -0

index 7e57fa3..115e0bf 100644
@@ -108,6 +108,7 @@ static struct clock_event_device *tick_get_oneshot_wakeup_device(int cpu)
 
 static void tick_oneshot_wakeup_handler(struct clock_event_device *wd)
 {
+	wd->next_event_forced = 0;
 	/*
 	 * If we woke up early and the tick was reprogrammed in the
 	 * meantime then this may be spurious but harmless.

Quoted 9 lines · On 4/16/26 21:26, tip-bot2 for Thomas Gleixner wrote:

The following commit has been merged into the timers/urgent branch of tip:

Commit-ID:     4096fd0e8eaea13ebe5206700b33f49635ae18e5
Gitweb:        https://git.kernel.org/tip/4096fd0e8eaea13ebe5206700b33f49635ae18e5
Author:        Thomas Gleixner <[email protected]>
AuthorDate:    Tue, 14 Apr 2026 22:55:01 +02:00
Committer:     Thomas Gleixner <[email protected]>
CommitterDate: Thu, 16 Apr 2026 21:22:04 +02:00

Quoted 1 line

clockevents: Add missing resets of the next_event_forced flag

Just wondering: what's the plan to mainline this? I wonder if this is worth mainlining rather quickly and the tell the stable team right afterwards to queue it up for 7.0.1, as in addition to the two affected people in this thread (one of which stated that "several users from CachyOS reported this regression as well") I noticed three more 7.0 bug reports in the past few days that likely are fixed by the quoted patch:

Quoted 10 lines · Linux regression tracking (Thorsten Leemhuis)

Quoted 9 lines · On 4/16/26 21:26, tip-bot2 for Thomas Gleixner wrote:

The following commit has been merged into the timers/urgent branch of tip:

Commit-ID:     4096fd0e8eaea13ebe5206700b33f49635ae18e5
Gitweb:        https://git.kernel.org/tip/4096fd0e8eaea13ebe5206700b33f49635ae18e5
Author:        Thomas Gleixner <[email protected]>
AuthorDate:    Tue, 14 Apr 2026 22:55:01 +02:00
Committer:     Thomas Gleixner <[email protected]>
CommitterDate: Thu, 16 Apr 2026 21:22:04 +02:00

Quoted 8 lines

Quoted 1 line

clockevents: Add missing resets of the next_event_forced flag

Just wondering: what's the plan to mainline this? I wonder if this is worth mainlining rather quickly and the tell the stable team right afterwards to queue it up for 7.0.1, as in addition to the two affected people in this thread (one of which stated that "several users from CachyOS reported this regression as well") I noticed three more 7.0 bug reports in the past few days that likely are fixed by the quoted patch:

It's in Linus tree and I asked the stable folks to withhold the original patch which it fixes, so they can queue both at once.

Quoted 20 lines · Thomas Gleixner

Quoted 10 lines · Linux regression tracking (Thorsten Leemhuis)

Quoted 9 lines · On 4/16/26 21:26, tip-bot2 for Thomas Gleixner wrote:

The following commit has been merged into the timers/urgent branch of tip:

Commit-ID:     4096fd0e8eaea13ebe5206700b33f49635ae18e5
Gitweb:        https://git.kernel.org/tip/4096fd0e8eaea13ebe5206700b33f49635ae18e5
Author:        Thomas Gleixner <[email protected]>
AuthorDate:    Tue, 14 Apr 2026 22:55:01 +02:00
Committer:     Thomas Gleixner <[email protected]>
CommitterDate: Thu, 16 Apr 2026 21:22:04 +02:00

Quoted 8 lines

Quoted 1 line

clockevents: Add missing resets of the next_event_forced flag

Just wondering: what's the plan to mainline this? I wonder if this is worth mainlining rather quickly and the tell the stable team right afterwards to queue it up for 7.0.1, as in addition to the two affected people in this thread (one of which stated that "several users from CachyOS reported this regression as well") I noticed three more 7.0 bug reports in the past few days that likely are fixed by the quoted patch:

Quoted 2 lines

It's in Linus tree and I asked the stable folks to withhold the original patch which it fixes, so they can queue both at once.

Yeah, I noticed, and many thx! Also many thx for planning the backport, this is great. But that "original patch" is already in 7.0, which makes me wonder:

Should we ask Greg (now CCed) to include a backport (once it exists) for 7.0.1, even if that is in testing already and might mean that this needs another stable-rc or delayed? Because in addition to those three reports I mentioned earlier I noticed one more today:
https://bugzilla.kernel.org/show_bug.cgi?id=221377

And maybe this is the same issue, too:
https://bugzilla.kernel.org/show_bug.cgi?id=221388

IOW: quite a few people are hitting this.

Quoted 34 lines · Thorsten Leemhuis

Quoted 20 lines · Thomas Gleixner

Quoted 10 lines · Linux regression tracking (Thorsten Leemhuis)

Quoted 9 lines · On 4/16/26 21:26, tip-bot2 for Thomas Gleixner wrote:

The following commit has been merged into the timers/urgent branch of tip:

Commit-ID:     4096fd0e8eaea13ebe5206700b33f49635ae18e5
Gitweb:        https://git.kernel.org/tip/4096fd0e8eaea13ebe5206700b33f49635ae18e5
Author:        Thomas Gleixner <[email protected]>
AuthorDate:    Tue, 14 Apr 2026 22:55:01 +02:00
Committer:     Thomas Gleixner <[email protected]>
CommitterDate: Thu, 16 Apr 2026 21:22:04 +02:00

Quoted 8 lines

Quoted 1 line

clockevents: Add missing resets of the next_event_forced flag

Just wondering: what's the plan to mainline this? I wonder if this is worth mainlining rather quickly and the tell the stable team right afterwards to queue it up for 7.0.1, as in addition to the two affected people in this thread (one of which stated that "several users from CachyOS reported this regression as well") I noticed three more 7.0 bug reports in the past few days that likely are fixed by the quoted patch:

Quoted 2 lines

It's in Linus tree and I asked the stable folks to withhold the original patch which it fixes, so they can queue both at once.

Yeah, I noticed, and many thx! Also many thx for planning the backport, this is great. But that "original patch" is already in 7.0, which makes me wonder:

Should we ask Greg (now CCed) to include a backport (once it exists) for 7.0.1, even if that is in testing already and might mean that this needs another stable-rc or delayed? Because in addition to those three reports I mentioned earlier I noticed one more today:
https://bugzilla.kernel.org/show_bug.cgi?id=221377

Quoted 4 lines

And maybe this is the same issue, too:
https://bugzilla.kernel.org/show_bug.cgi?id=221388

IOW: quite a few people are hitting this.

I've already dropped this from all of the other stable queues. If you want me to pick up something from linux-next now, for 7.0.1, I'll be glad to do so, just let me know.

kernel/time/hrtimer.c +9 -11

+enum {
+	HRTIMER_REPROGRAM_NONE,
+	HRTIMER_REPROGRAM,
+	HRTIMER_REPROGRAM_FORCE,
+};
 
+static int hrtimer_start_range_ns_common(struct hrtimer *timer, ktime_t tim,
+					 u64 delta_ns, const enum hrtimer_mode mode,
+					 struct hrtimer_clock_base *base)

@@ -1315,25 +1337,110 @@ void hrtimer_start_range_ns(struct hrtim
 	struct hrtimer_clock_base *base;
 	unsigned long flags;
 
-	/*
-	 * Check whether the HRTIMER_MODE_SOFT bit and hrtimer.is_soft
-	 * match on CONFIG_PREEMPT_RT = n. With PREEMPT_RT check the hard
-	 * expiry mode because unmarked timers are moved to softirq expiry.
-	 */
-	if (!IS_ENABLED(CONFIG_PREEMPT_RT))
-		WARN_ON_ONCE(!(mode & HRTIMER_MODE_SOFT) ^ !timer->is_soft);
-	else
-		WARN_ON_ONCE(!(mode & HRTIMER_MODE_HARD) ^ !timer->is_hard);
-
 	base = lock_hrtimer_base(timer, &flags);
 
-	if (__hrtimer_start_range_ns(timer, tim, delta_ns, mode, base))
+	switch (hrtimer_start_range_ns_common(timer, tim, delta_ns, mode, base)) {

Quoted 10 lines · Thomas Gleixner

kernel/time/hrtimer.c +7 -1

-	if (__hrtimer_start_range_ns(timer, tim, delta_ns, mode, base))
+	switch (hrtimer_start_range_ns_common(timer, tim, delta_ns, mode, base)) {
+	case HRTIMER_REPROGRAM:
 		hrtimer_reprogram(timer, true);
+		break;
+	case HRTIMER_REPROGRAM_FORCE:
+		hrtimer_force_reprogram(timer->base->cpu_base, 1);
+		break;
+	}

Quoted 2 lines

unlock_hrtimer_base(timer, &flags);
}

Something is going to figure out that hrtimer_start_range_ns_common() is really returning that enum and then complain you don't handle NONE :-)

Anyway, to me it would make sense to instead pass that value to hrtimer_reprogram() as the second argument. But this works I suppose.

kernel/time/hrtimer.c +78 -0

+static inline bool hrtimer_check_user_timer(struct hrtimer *timer)
+{
+	struct hrtimer_cpu_base *cpu_base = timer->base->cpu_base;
+	ktime_t expires;
+
+	/*
+	 * This uses soft expires because that's the user provided
+	 * expiry time, while expires can be further in the past
+	 * due to a slack value added to the user expiry time.
+	 */
+	expires = hrtimer_get_softexpires(timer);
+
+	/* Convert to monotonic */
+	expires = ktime_sub(expires, timer->base->offset);
+
+	/*
+	 * Check whether this timer will end up as the first expiring timer in
+	 * the CPU base. If not, no further checks required as it's then
+	 * guaranteed to expire in the future.
+	 */
+	if (expires >= cpu_base->expires_next)
+		return true;
+
+	/* Validate that the expiry time is in the future. */
+	if (expires > ktime_get())
+		return true;
+
+	debug_deactivate(timer);
+	__remove_hrtimer(timer, timer->base, HRTIMER_STATE_INACTIVE, false);
+	trace_hrtimer_start_expired(timer);
+	return false;
+}
+
+static bool hrtimer_reprogram_user(struct hrtimer *timer)
+{
+	if (!hrtimer_check_user_timer(timer))
+		return false;
+	hrtimer_reprogram(timer, true);
+	return true;
+}
+
+static bool hrtimer_force_reprogram_user(struct hrtimer *timer)
+{
+	bool ret = hrtimer_check_user_timer(timer);
+
+	/*
+	 * The base must always be reevaluated, independent of the result
+	 * above because the timer was the first pending timer.
+	 */
+	hrtimer_force_reprogram(timer->base->cpu_base, 1);
+	return ret;
+}
+
+/**
+ * hrtimer_start_range_ns_user - (re)start an user controlled hrtimer
+ * @timer:	the timer to be added
+ * @tim:	expiry time
+ * @delta_ns:	"slack" range for the timer
+ * @mode:	timer mode: absolute (HRTIMER_MODE_ABS) or
+ *		relative (HRTIMER_MODE_REL), and pinned (HRTIMER_MODE_PINNED);
+ *		softirq based mode is considered for debug purpose only!
+ *
+ * Returns: True when the timer was queued, false if it was already expired
+ *
+ * This function cannot invoke the timer callback for expired timers as it might
+ * be called under a lock which the timer callback needs to acquire. So the
+ * caller has to handle that case.
+ */
+bool hrtimer_start_range_ns_user(struct hrtimer *timer, ktime_t tim,
+				 u64 delta_ns, const enum hrtimer_mode mode)
+{
+	struct hrtimer_clock_base *base;
+	unsigned long flags;
+	bool ret = true;
+
+	base = lock_hrtimer_base(timer, &flags);
+	switch (hrtimer_start_range_ns_common(timer, tim, delta_ns, mode, base)) {
+	case HRTIMER_REPROGRAM:

kernel/time/hrtimer.c void hrtimer_start_range_ns(struct hrtim · line 1442

Quoted 3 lines · Thomas Gleixner

kernel/time/hrtimer.c +3 -0

+	return ret;
+}
+EXPORT_SYMBOL_GPL(hrtimer_start_range_ns_user);

Can we do that hrtimer_check_user_timer() in hrtimer_start_range_ns_user() and then not duplicate hrtimer_*reprogram() ?

Most hrtimer sleepers are user controlled and user space can hand arbitrary expiry values in as long as they are valid timespecs. If the expiry value is in the past then this requires a full loop through reprogramming the clock event device, taking the hrtimer interrupt, waking the task and reprogram again.

Use hrtimer_start_expires_user() which avoids the full round trip by checking the timer for expiry on enqueue.

Signed-off-by Thomas Gleixner <[email protected]>

Cc Anna-Maria Behnsen <[email protected]>

Cc Frederic Weisbecker <[email protected]>

---
 kernel/time/hrtimer.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

kernel/time/hrtimer.c +5 -1

@@ -2152,7 +2152,11 @@ void hrtimer_sleeper_start_expires(struc
 	if (IS_ENABLED(CONFIG_PREEMPT_RT) && sl->timer.is_hard)
 		mode |= HRTIMER_MODE_HARD;
 
-	hrtimer_start_expires(&sl->timer, mode);
+	/* If already expired, clear the task pointer and set current state to running */
+	if (!hrtimer_start_expires_user(&sl->timer, mode)) {
+		sl->task = NULL;
+		__set_current_state(TASK_RUNNING);
+	}
 }
 EXPORT_SYMBOL_GPL(hrtimer_sleeper_start_expires);
 

In order to catch expiry times which are already in the past the timer_arm() and timer_rearm() callbacks need to be able to report back to the caller whether the timer has been queued or not.

Change the function signature and let all implementations return true for now. While at it simplify posix_cpu_timer_rearm().

No functional change intended.

Signed-off-by Thomas Gleixner <[email protected]>

In order to catch expiry times which are already in the past the timer_arm() and timer_rearm() callbacks need to be able to report back to the caller whether the timer has been queued or not.

Change the function signature and let all implementations return true for now. While at it simplify posix_cpu_timer_rearm().

No functional change intended.

Signed-off-by Thomas Gleixner <[email protected]>

Cc John Stultz <[email protected]>

Cc Stephen Boyd <[email protected]>

Cc Anna-Maria Behnsen <[email protected]>

Cc Frederic Weisbecker <[email protected]>

The [re]arm callbacks will return true when the timer was queued and false if it was already expired at enqueue time.

In both cases the call sites can trivially queue the signal right there, when the timer was already expired.

Signed-off-by Thomas Gleixner <[email protected]>

Switch the arm and rearm callbacks for hrtimer based posix timers over to hrtimer_start_expires_user() so that already expired timers are not queued. Hand the result back to the caller, which then queues the signal.

Signed-off-by Thomas Gleixner <[email protected]>

Alarm timers utilize hrtimers for normal operation and only switch to the RTC on suspend. In order to catch already expired timers early and without going through a timer interrupt cycle, provide a new start function which internally uses hrtimer_start_range_ns_user().

If hrtimer_start_range_ns_user() detects an already expired timer, it does not queue it. In that case remove the timer from the alarm base as well.

Return the status queued or not back to the caller to handle the early expiry.

Signed-off-by Thomas Gleixner <[email protected]>

Quoted 5 lines · Thomas Gleixner

Alarm timers utilize hrtimers for normal operation and only switch to the RTC on suspend. In order to catch already expired timers early and without going through a timer interrupt cycle, provide a new start function which internally uses hrtimer_start_range_ns_user().

Quoted 7 lines

If hrtimer_start_range_ns_user() detects an already expired timer, it does not queue it. In that case remove the timer from the alarm base as well.

Return the status queued or not back to the caller to handle the early expiry.

Signed-off-by Thomas Gleixner <[email protected]>

Not familiar with this code, but my head hurts from the:

alarm_
alarm_timer_
alarmtimer_

prefixes, what's what?

Alarm timers utilize hrtimers for normal operation and only switch to the RTC on suspend. In order to catch already expired timers early and without going through a timer interrupt cycle, provide a new start function which internally uses hrtimer_start_range_ns_user().

If hrtimer_start_range_ns_user() detects an already expired timer, it does not queue it. In that case remove the timer from the alarm base as well.

Return the status queued or not back to the caller to handle the early expiry.

Signed-off-by Thomas Gleixner <[email protected]>

Cc John Stultz <[email protected]>

Cc Stephen Boyd <[email protected]>

Use the new alarmtimer_start() for arming and rearming posix interval timers and for clock_nanosleep() so that already expired timers do not go through the full timer interrupt cycle.

Signed-off-by Thomas Gleixner <[email protected]>

Cc John Stultz <[email protected]>

Cc Stephen Boyd <[email protected]>

---
 kernel/time/alarmtimer.c |   20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

fs/timerfd.c +29 -17

+
+	timerfd_alarm_start(ctx, alarm_get_expires(&ctx->t.alarm), false);
+	return ticks;
+}
+
+static void timerfd_hrtimer_start(struct timerfd_ctx *ctx, ktime_t exp,
+				  const enum hrtimer_mode mode)
+{
+	/* Start the timer. If it's expired already, handle the callback. */
+	if (!hrtimer_start_range_ns_user(&ctx->t.tmr, exp, 0, mode))
+		__timerfd_triggered(ctx);
+}
+
+static u64 timerfd_hrtimer_restart(struct timerfd_ctx *ctx)
+{
+	u64 ticks = hrtimer_forward_now(&ctx->t.tmr, ctx->tintv) - 1;
+
+	timerfd_hrtimer_start(ctx, hrtimer_get_expires(&ctx->t.tmr), HRTIMER_MODE_ABS);
+	return ticks;
+}
 
-		if (ctx->expired && ctx->tintv) {
-			/*
-			 * If tintv != 0, this is a periodic timer that
-			 * needs to be re-armed. We avoid doing it in the timer
-			 * callback to avoid DoS attacks specifying a very
-			 * short timer period.
-			 */
-			if (isalarm(ctx)) {
-				ticks += alarm_forward_now(
-					&ctx->t.alarm, ctx->tintv) - 1;
-				alarm_restart(&ctx->t.alarm);
-			} else {
-				ticks += hrtimer_forward_now(&ctx->t.tmr,
-							     ctx->tintv) - 1;
-				hrtimer_restart(&ctx->t.tmr);
-			}
-		}
+		ticks = ctx->ticks;
 		ctx->expired = 0;
 		ctx->ticks = 0;
+
+		/*
+		 * If tintv != 0, this is a periodic timer that needs to be
+		 * re-armed. We avoid doing it in the timer callback to avoid
+		 * DoS attacks specifying a very short timer period.
+		 */
+		if (expired && ctx->tintv)
+			ticks += timerfd_restart(ctx);
 	}
 	spin_unlock_irq(&ctx->wqh.lock);
 	if (ticks) {

@@ -526,18 +554,7 @@ static int do_timerfd_gettime(int ufd, s
 	spin_lock_irq(&ctx->wqh.lock);
 	if (ctx->expired && ctx->tintv) {
 		ctx->expired = 0;

fs/timerfd.c static int do_timerfd_gettime(int ufd, s · line 538

Quoted 3 lines

fs/timerfd.c +0 -3

-			ctx->ticks +=
-				hrtimer_forward_now(&ctx->t.tmr, ctx->tintv)
-				- 1;

(argh!)

fs/timerfd.c static int do_timerfd_gettime(int ufd, s · line 560

Quoted 6 lines

fs/timerfd.c +1 -2

-			hrtimer_restart(&ctx->t.tmr);
-		}
+		ctx->ticks += timerfd_restart(ctx);
 	}
 	t->it_value = ktime_to_timespec64(timerfd_get_remaining(ctx));
 	t->it_interval = ktime_to_timespec64(ctx->tintv);

What's with the -1 thing?

All alarmtimer users are converted to alarmtimer_start(). Remove the now unused interfaces.

Signed-off-by Thomas Gleixner <[email protected]>

Cc John Stultz <[email protected]>

Cc Stephen Boyd <[email protected]>

There needs to be some discussion about the scope of backporting. The first patch preventing the stall is obviously a backport candidate. The remaining series can be obviously argued about, but in my opinion it should be backported as well as it prevents stupid or malicious user space from generating tons of pointless timer interrupts.

Quoted 5 lines · Thomas Gleixner

There needs to be some discussion about the scope of backporting. The first patch preventing the stall is obviously a backport candidate. The remaining series can be obviously argued about, but in my opinion it should be backported as well as it prevents stupid or malicious user space from generating tons of pointless timer interrupts.

Peter and me just discussed it over IRC. With the clockevents prevention in place, the effect of stupid/malicious code is pretty much affecting only the user space task itself. As the timer is forced to expire once the clockevent device has been force armed, it won't have other side effects as device interrupts or IPIs are not blocked out and in the worst case marginally delayed by the high frequency timer interrupt.

Once the task is scheduled out that subsides as there is nothing which re-arms the timer anymore.

So we should be fine with backporting the clockevents fix and leave the other parts of the series for upstream only. I still need to investigate how all of that affects the pending changes vs. TSC deadline timer (and similar devices) which are not going to reach that modified clockevents code anymore.

Calvin reported an odd NMI watchdog lockup which claims that the CPU locked up in user space:

https://lore.kernel.org/lkml/[email protected]/

He provided a reproducer, which sets 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 first patch in the series changes the clockevent set next event mechanism to prevent reprogramming of the clockevent device when the minimum delta value was programmed unless the new delta is larger than that. It's a less convoluted variant of the patch which was posted in the above linked thread and was confirmed to prevent the starvation problem.

But that's only to be considered the last resort because it results in an insane amount of avoidable hrtimer interrupts.

The problem of user controlled timers is that the input value is only sanity checked vs. validity of the provided timespec and clamped to be in the maximum allowable range. But for performance reasons for in kernel usage there is no check whether a to be armed timer might have been expired already at enqueue time.

The rest of the series addresses this by providing a separate interface to arm user controlled timers. This works the same way as the existing hrtimer_start_range_ns(), but in case that the timer ends up as the first timer in the clock base after enqueue it provides additional checks:

- Whether the timer becomes the first expiring timer in the CPU base.

If not the timer is considered to expire in the future as there is already an earlier event programmed.

- Whether the timer has expired already by comparing the expiry value against current time.

If it is expired, the timer is removed from the clock base and the function returns false, so that the caller can handle it. That's required because the function cannot invoke the callback as that might need to acquire a lock which is held by the caller.

This function is then used for the user controlled timer arming interfaces mainly by converting hrtimer sleeper over to it. That affects a few in kernel users too, but the overhead is minimal in that case and it spares a tedious whack the mole game all over the tree.

The other usage sites in posixtimers, alarmtimers and timerfd are converted as well, which should cover the vast majority of user space controllable timers as far as my investigation goes.

The series applies against Linux tree and is also available from git:

git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git hrtimer-exp-v1

There needs to be some discussion about the scope of backporting. The first patch preventing the stall is obviously a backport candidate. The remaining series can be obviously argued about, but in my opinion it should be backported as well as it prevents stupid or malicious user space from generating tons of pointless timer interrupts.

Thanks,

tglx

---
 drivers/power/supply/charger-manager.c |   12 +-
 fs/timerfd.c                           |  115 +++++++++++++++-----------
 include/linux/alarmtimer.h             |    9 +-
 include/linux/clockchips.h             |    2 
 include/linux/hrtimer.h                |   20 +++-
 include/trace/events/timer.h           |   13 +++
 kernel/time/alarmtimer.c               |   70 +++++++---------
 kernel/time/clockevents.c              |   23 +++--
 kernel/time/hrtimer.c                  |  142 +++++++++++++++++++++++++++++----
 kernel/time/posix-cpu-timers.c         |   18 ++--
 kernel/time/posix-timers.c             |   35 +++++---
 kernel/time/posix-timers.h             |    4 
 kernel/time/tick-common.c              |    1 
 kernel/time/tick-sched.c               |    1 
 net/netfilter/xt_IDLETIMER.c           |   24 ++++-
 15 files changed, 341 insertions(+), 148 deletions(-)

Quoted 2 lines · Thomas Gleixner

He provided a reproducer, which sets up a timerfd based timer and then rearms it in a loop with an absolute expiry time of 1ns.

The original AMD machines survive the reproducer with this series.

Tested-by Calvin Owens <[email protected]>

I'm happy to test subsets of it and stable backports too, if that's helpful, just let me know.

Quoted 6 lines · Calvin Owens

Quoted 2 lines · Thomas Gleixner

He provided a reproducer, which sets up a timerfd based timer and then rearms it in a loop with an absolute expiry time of 1ns.

The original AMD machines survive the reproducer with this series.

Quoted 4 lines

Tested-by Calvin Owens <[email protected]>

I'm happy to test subsets of it and stable backports too, if that's helpful, just let me know.

We'll only backport the first patch, so confirming that it still prevents the issue would be nice. The rest is slated for upstream only.

Quoted 9 lines · Thomas Gleixner

Quoted 8 lines · Calvin Owens

Quoted 2 lines · Thomas Gleixner

He provided a reproducer, which sets up a timerfd based timer and then rearms it in a loop with an absolute expiry time of 1ns.

The original AMD machines survive the reproducer with this series.

Tested-by Calvin Owens <[email protected]>

Quoted 5 lines

Quoted 2 lines

I'm happy to test subsets of it and stable backports too, if that's helpful, just let me know.

We'll only backport the first patch, so confirming that it still prevents the issue would be nice. The rest is slated for upstream only.

Confirmed, [1/12] alone passes.