From: "Xogium" <contact@xogium.me>
To: <linux-arm-kernel@lists.infradead.org>
Cc: Will Deacon <will@kernel.org>
Subject: [breakage] panic() does not halt arm64 systems under certain conditions
Date: Mon, 16 Sep 2019 21:35:36 -0400 [thread overview]
Message-ID: <BX1W47JXPMR8.58IYW53H6M5N@dragonstone> (raw)
On arm64 in some situations userspace will continue running even after a panic. This means any userspace watchdog daemon will continue pinging, that service
managers will keep running and displaying messages in certain cases, and that it is possible to enter via ssh in the now unstable system and to do almost
anything except reboot/power off and etc. If CONFIG_PREEMPT=n is set in the kernel's configuration, the issue is fixed. I have reproduced the very same behavior
with linux 4.19, 5.2 and 5.3. On x86/x86_64 the issue does not seem to be present at all. Also, kernels without commit 8341f2f222d729688014ce8306727fdb9798d37e
don't trigger a broken panic using 'echo c > /proc/sysrq-trigger', instead they call die() through the memory manager which works as intended, because it causes
an oops which ends in a panic, and don't call the panic() function directly. By patching the poweroff sysrq-trigger to panic i can confirm the issue is
definitely present in kernel 4.19 on qemu. On actual hardware I used a marvell ESPRESSOBin with linux 5.2.14. The issue seemed to be quite random at first, but
it can be triggered 100% of the time by adding nosmp on the kernel command line. Also if e.g: panic=30 is added on the kernel command line, the problem is also
worked around and disappears entirely, using nosmp or not.
The easiest way to reproduce this is using qemu and this initramfs containing busybox and the following init script:
#!/bin/sh
busybox mkdir /proc
busybox mount -t proc none /proc
# Launch some programs to run in the background
while true; do echo "Ping 1!"; busybox sleep 1; done >/dev/console&
while true; do echo "Ping 2!"; busybox sleep 2; done >/dev/console&
echo c > /proc/sysrq-trigger
# Nothing should be running from here on out
echo "Running a shell now!"
exec busybox sh
A copy of the initramfs and a 5.2 arm64 defconfig kernel can be found at:
http://novena.jookia.org/arm64bug/mycpio
http://novena.jookia.org/arm64bug/Image
You can run it in qemu using:
qemu-system-aarch64 -machine virt-4.0 -cpu cortex-a53 -m 256 -kernel Image -initrd mycpio -nographic
As an example, running it with linux 5.2.15 with the arm64 defconfig in qemu gives this:
[ 1.841502] Run /init as init process
[ 1.970386] sysrq: Trigger a crash
[ 1.970967] Kernel panic - not syncing: sysrq triggered crash
[ 1.971693] CPU: 0 PID: 1 Comm: init Not tainted 5.2.15 #1
[ 1.972096] Hardware name: linux,dummy-virt (DT)
[ 1.972661] Call trace:
[ 1.972919] dump_backtrace+0x0/0x148
[ 1.973271] show_stack+0x14/0x20
[ 1.973472] dump_stack+0xa0/0xc4
[ 1.973699] panic+0x140/0x32c
[ 1.973897] sysrq_handle_reboot+0x0/0x20
[ 1.974161] __handle_sysrq+0x124/0x190
[ 1.974422] write_sysrq_trigger+0x64/0x88
[ 1.974715] proc_reg_write+0x60/0xa8
[ 1.974973] __vfs_write+0x18/0x40
[ 1.975224] vfs_write+0xa4/0x1b8
[ 1.975474] ksys_write+0x64/0xf0
[ 1.975739] __arm64_sys_write+0x14/0x20
[ 1.976021] el0_svc_common.constprop.0+0xb0/0x168
[ 1.976375] el0_svc_handler+0x28/0x78
[ 1.976661] el0_svc+0x8/0xc
[ 1.977383] Kernel Offset: disabled
[ 1.977895] CPU features: 0x0002,24002004
[ 1.978241] Memory Limit: none
[ 1.979169] ---[ end Kernel panic - not syncing: sysrq triggered crash ]---
Ping 2!
Ping 1!
Ping 1!
Ping 2!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2019-09-17 1:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-17 1:35 Xogium [this message]
2019-09-17 10:45 ` [breakage] panic() does not halt arm64 systems under certain conditions Will Deacon
2019-09-17 10:51 ` Russell King - ARM Linux admin
2019-09-17 11:05 ` Will Deacon
2019-09-20 4:25 ` Jookia
2019-09-30 13:53 ` Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BX1W47JXPMR8.58IYW53H6M5N@dragonstone \
--to=contact@xogium.me \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).