Re: [PATCH v2 5/6] entry,hrtimer: Push reprogramming timers into the interrupt return path

[Peter Zijlstra <peterz@infradead.org>]

On Mon, Feb 02, 2026 at 03:37:13PM +0100, Thomas Gleixner wrote:
> On Wed, Jan 21 2026 at 17:20, Peter Zijlstra wrote:
> >  	while (ti_work & EXIT_TO_USER_MODE_WORK_LOOP) {
> >  
> > +		/*
> > +		 * If hrtimer need re-arming, do so before enabling IRQs,
> > +		 * except when a reschedule is needed, in that case schedule()
> > +		 * will do this.
> > +		 */
> > +		if ((ti_work & (_TIF_NEED_RESCHED |
> > +				_TIF_NEED_RESCHED_LAZY |
> > +				_TIF_HRTIMER_REARM)) == _TIF_HRTIMER_REARM)
> > +			hrtimer_rearm();
> 
> Two things I'm not convinced that they are handled correctly:
> 
>     1) Interrupts
> 
>        After reenabling interrupts and before reaching schedule() an
>        interrupt comes in and runs soft interrupt processing for a while
>        on the way back, which delays the update until that processing
>        completes.

So the basic thing looks like:

      <USER-MODE>
	irqentry_enter()
	run_irq_on_irqstack_cond()
	  if (user_mode() || hardirq_stack_inuse)
	    irq_enter_rcu();
	    func_c();
	    irq_exit_rcu()
	      __irq_exit_rcu()
	        invoke_softirq()
	irqentry_exit()
	  irqentry_exit_to_user_mode()
	    irqentry_exit_to_user_mode_prepare()
	      __exit_to_user_mode_prepare()
	        exit_to_user_mode_loop() 
		  ...here...

So a nested IRQ at this point will have !user_mode(), but I think it can
still end up in softirqs due to that hardirq_stack_inuse. Should we
perhaps make sure only user_mode() ends up in softirqs?

>     2) Time slice extension
> 
>        When the time slice is granted this will not rearm the clockevent
>        device unless the slice hrtimer becomes the first expiring timer
>        on that CPU, but even then that misses the full reevaluation of
>        the next timer event.

Oh crud yes, that should be something like:

		if (!rseq_grant_slice_extension(ti_work & TIF_SLICE_EXT_DENY))
			schedule();
		else
			hrtimer_rearm();