Subject: Re: [linux-next][s390] Boot hang after merge c50f05bd3c4e (sched/hrtick)

From: Peter Zijlstra <[email-masked]>
Date: Thu, 5 Mar 2026 14:07:25 +0100

On Thu, Mar 05, 2026 at 01:45:01PM +0100, Peter Zijlstra wrote:
> On Thu, Mar 05, 2026 at 01:35:05PM +0100, Peter Zijlstra wrote:
> > On Thu, Mar 05, 2026 at 01:12:01PM +0100, Peter Zijlstra wrote:
> > 
> > > > Any idea?
> > > 
> > > Well, that all looks like timers are going missing. Which matches with
> > > Sven saying that disabling HRTIMER_REARM_DEFERRED makes it go again.
> > > 
> > > I'm just not sure I can see why things would break between
> > > sched/hrtick (GOOD) and 1b8b1bb2a2fa (BAD).
> > > 
> > > Looking at the diff (eg git diff d50da4b5915f..c50f05bd3c4e) show some
> > > idle time changes to s390 and various kernel/ changes, but nothing that
> > > stands out to me :/
> > 
> > That s390 idle time code..
> > 
> >   0d785e2c324c ("s390/idle: Fix cpu idle exit cpu time accounting")
> > 
> > That moves this_cpu_add() from inside irq_enter_rcu() / irq_exit_rcu()
> > to outside of it.
> > 
> > Your this_cpu_add() as preempt_enable(), which does a preemption check.
> > 
> > Moving that before irq_enter_rcu() means it doesn't see HARDIRQ_OFFSET
> > in preempt_count(). As such, it might actually call into schedule() from
> > hardirq context.
> > 
> > Or am I missing something?
> 
> N/m, it turns into __this_cpu_add() and that doesn't have
> preempt_enable().
> 
> 00d8b035eb71 ("s390/idle: Slightly optimize idle time accounting")
> 
> Is actually a correctness fix afaict.

Another change is that you clear I and E in the PSW bit before
irq_enter_rcu(), which, per:

  7e641e52cf5f ("softirq: Prepare for deferred hrtimer rearming")

can re-arm the timer.

So where previously it would re-arm and still have the I/E bits set, so
the timer could fire, they are now disabled.

I really don't know if this is a problem; I'm clutching at s390 straws
here that I really don't know much about.