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 <[email protected]>
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 <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: Alexei Starovoitov <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Daniel Borkmann <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Nadav Amit <[email protected]>
Cc: Rik van Riel <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
:040000 040000 58066de53107eab0705398b5d0c407424c138a86
7a1345d43c4cacee60b9135899b775ecdb54ea7e M include
:040000 040000 d02692cf57a359056b34e636d0f102d37de5b264
81c4c2c6408b68eb555673bd3f0bc3071db1f7ed M kernel
--
Meelis Roos <[email protected]>
