On Mon, 2019-05-13 at 17:01 +0300, Meelis Roos wrote: > I tested yesterdays 5.2 devel git and it failed to boot on my Sun Fire V445 > (4x UltraSparc III). Init is started and it hangs there: > > [ 38.414436] Run /sbin/init as init process > [ 38.530711] random: fast init done > [ 39.580678] systemd[1]: Inserted module 'autofs4' > [ 39.721577] systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT > +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS > +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default- > hierarchy=hybrid) > [ 40.028068] systemd[1]: Detected architecture sparc64. > > Welcome to Debian GNU/Linux 10 (buster)! > > [ 40.168713] systemd[1]: Set hostname to <v445>. > [ 61.318034] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: > [ 61.403039] rcu: 1-...!: (0 ticks this GP) > idle=602/1/0x4000000000000000 softirq=85/85 fqs=1 > [ 61.526780] rcu: (detected by 3, t=5252 jiffies, g=-967, q=228) > [ 61.613037] CPU[ 1]: TSTATE[0000000080001602] TPC[000000000043f2b8] > TNPC[000000000043f2bc] TASK[systemd-fstab-g:90] > [ 61.766828] TPC[smp_synchronize_tick_client+0x18/0x180] > O7[__do_munmap+0x204/0x3e0] I7[xcall_sync_tick+0x1c/0x2c] > RPC[page_evictable+0x4/0x60] > [ 61.966807] rcu: rcu_sched kthread starved for 5250 jiffies! g-967 f0x0 > RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=2 > [ 62.113058] rcu: RCU grace-period kthread stack dump: > [ 62.185558] rcu_sched I 0 10 2 0x06000000 > [ 62.264312] Call Trace: > [ 62.299316] [000000000092a1fc] schedule+0x1c/0x80 > [ 62.368071] [000000000092d3fc] schedule_timeout+0x13c/0x280 > [ 62.449328] [00000000004b6c64] rcu_gp_kthread+0x4c4/0xa40 > [ 62.528077] [000000000047e95c] kthread+0xfc/0x120 > [ 62.596833] [00000000004060a4] ret_from_fork+0x1c/0x2c > [ 62.671831] [0000000000000000] (null) > > 5.1.0 worked fine. I bisected it to the following commit: > > d53d2f78ceadba081fc7785570798c3c8d50a718 is the first bad commit > commit d53d2f78ceadba081fc7785570798c3c8d50a718 > Author: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx> > Date: Thu Apr 25 17:11:38 2019 -0700 > > bpf: Use vmalloc special flag > > Use new flag VM_FLUSH_RESET_PERMS for handling freeing of special > permissioned memory in vmalloc and remove places where memory was set RW > before freeing which is no longer needed. Don't track if the memory is RO > anymore because it is now tracked in vmalloc. > > Signed-off-by: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx> > Signed-off-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx> > Cc: <akpm@xxxxxxxxxxxxxxxxxxxx> > Cc: <ard.biesheuvel@xxxxxxxxxx> > Cc: <deneen.t.dock@xxxxxxxxx> > Cc: <kernel-hardening@xxxxxxxxxxxxxxxxxx> > Cc: <kristen@xxxxxxxxxxxxxxx> > Cc: <linux_dti@xxxxxxxxxx> > Cc: <will.deacon@xxxxxxx> > Cc: Alexei Starovoitov <ast@xxxxxxxxxx> > Cc: Andy Lutomirski <luto@xxxxxxxxxx> > Cc: Borislav Petkov <bp@xxxxxxxxx> > Cc: Daniel Borkmann <daniel@xxxxxxxxxxxxx> > Cc: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx> > Cc: H. Peter Anvin <hpa@xxxxxxxxx> > Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> > Cc: Nadav Amit <nadav.amit@xxxxxxxxx> > Cc: Rik van Riel <riel@xxxxxxxxxxx> > Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > Link: https://lkml.kernel.org/r/20190426001143.4983-19-namit@xxxxxxxxxx > Signed-off-by: Ingo Molnar <mingo@xxxxxxxxxx> > > :040000 040000 58066de53107eab0705398b5d0c407424c138a86 > 7a1345d43c4cacee60b9135899b775ecdb54ea7e M include > :040000 040000 d02692cf57a359056b34e636d0f102d37de5b264 > 81c4c2c6408b68eb555673bd3f0bc3071db1f7ed M kernel > Thanks, I'll see if I can reproduce. Rick
