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

[Heiko Carstens <hca@linux.ibm.com>]

On Wed, Mar 04, 2026 at 05:13:56PM +0100, Mikhail Zaslonko wrote:
> Sorry, forgot to Cc a few people.
> Adding scheduler maintainers.
> 
> Thanks,
> Mikhail Zaslonko
> 
> On 03-Mar-26 19:31, Mikhail Zaslonko wrote:
> > Hello,
> > 
> > we have kernel-next boot hang on s390 starting next-20260302.
> > 
> > I bisected it in linux-next to:
> > 
> > c50f05bd3c4e ("Merge branch into tip/master: 'sched/hrtick'")
> > 
> > Good:
> >   72a2ab46f045  
> >   d50da4b5915f  (2nd parent: sched/hrtick branch)
> > 
> > Bad:
> >   c50f05bd3c4e  (merge commit)
> > 
> > Environment:
> >  - s390 under z/VM
> >  - many CPUs defined (32+)
> >  - boot hangs early with RCU stall (see boot log excerpt below)

linux-next is currently completely broken because of this.

Looking at one of the numerous dumps of linux-next from 20260303 I can
see that the system hangs early waiting for synchronize_rcu_normal()
to finish:

crash> ps
      PID    PPID  CPU       TASK        ST  %MEM      VSZ      RSS  COMM
>       0       0   0     3b7dff6c700    RU   0.0        0        0  [swapper/0]
>       0       0   1      80afc800      RU   0.0        0        0  [swapper/1]
>       0       0   2      80afa400      RU   0.0        0        0  [swapper/2]
>       0       0   3      80b34800      RU   0.0        0        0  [swapper/3]
>       0       0   4      80b32400      RU   0.0        0        0  [swapper/4]
>       0       0   5      80b30000      RU   0.0        0        0  [swapper/5]
>       0       0   6      80b14800      RU   0.0        0        0  [swapper/6]
>       0       0   7      80b50000      RU   0.0        0        0  [swapper/7]
>       0       0   8      80b3c800      RU   0.0        0        0  [swapper/8]
        1       0   3      80a80000      UN   0.0        0        0  swapper/0

Everything is idle. PID 1 is in uninterruptible sleep:

crash> bt 1
PID: 1        TASK: 80a80000          CPU: 3    COMMAND: "swapper/0"
 #0 [337de307a50] __schedule at 3b7df34708c
 #1 [337de307ac8] schedule at 3b7df3475ec
 #2 [337de307af8] schedule_timeout at 3b7df34fd78
 #3 [337de307b80] __wait_for_common at 3b7df348482
 #4 [337de307c18] wait_for_completion_state at 3b7df348658
 #5 [337de307c38] __wait_rcu_gp at 3b7de561da8
 #6 [337de307c98] synchronize_rcu_normal at 3b7de56ba12
 #7 [337de307d78] kern_unmount at 3b7de8a8f86
 #8 [337de307da8] do_sysctl_args at 3b7de94f2fa
 #9 [337de307e20] kernel_init at 3b7df3448b0
#10 [337de307e38] __ret_from_fork at 3b7de46dffc
#11 [337de307ea0] ret_from_fork at 3b7df3514b2

The corresponding rcu_synchronize structure on the stack:

crash> struct rcu_synchronize 0x337de307d80
struct rcu_synchronize {
  head = {
    next = 0x822a62a8,
    func = 0x3b7de561a90 <wakeme_after_rcu>
  },
  completion = {
    done = 0,
    wait = {
      lock = {
        raw_lock = {
          lock = 0
        }
      },
      task_list = {
        next = 0x337de307c50,
        prev = 0x337de307c50
      }
    }
  },
  oldstate = {
    rgos_norm = 0,
    rgos_exp = 0
  }
}

Any idea?