lkml.org 
[lkml]   [2022]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: x86_64/kvm: kernel hangs on poweroff
On 7/26/22 2:02 AM, Linus Torvalds wrote:
> On Mon, Jul 25, 2022 at 11:40 AM Yury Norov <yury.norov@gmail.com> wrote:
>>> [ 22.162259] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
>>> [ 22.163539] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.19.0-rc6 #198
>>> [ 22.164327] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
>>> [ 22.164327] Call Trace:
>>> [ 22.164327] <TASK>
>>> [ 22.164327] dump_stack_lvl+0x34/0x44
>>> [ 22.164327] panic+0x107/0x28a
>>> [ 22.164327] do_exit.cold+0x15/0x15
>>> [ 22.164327] ? sys_off_notify+0x3e/0x60
>>> [ 22.164327] __do_sys_reboot+0x1df/0x220
>>> [ 22.164327] ? vfs_writev+0xc7/0x190
>>> [ 22.164327] ? virtio_crypto_ctrl_vq_request+0xd0/0xd0
>>> [ 22.164327] ? fpregs_assert_state_consistent+0x1e/0x40
>>> [ 22.164327] do_syscall_64+0x3b/0x90
>>> [ 22.164327] entry_SYSCALL_64_after_hwframe+0x46/0xb0
>>> [ 22.164327] RIP: 0033:0x7f42b4118443
>>> [ 22.164327] Code: 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 89 fa be 69 19 12 28 bf ad de e1 fe b8 a9 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 05 c3 0f 1f 40 00 48 8b 15 f9 c9 0d 00 f7 d8
>
> That's literally the "exit()" system call.

I took a look and it turned out it's not the "exit()" system call.

The disassembly is:

0: 64 89 01 mov %eax,%fs:(%rcx)
3: 48 83 c8 ff or $0xffffffffffffffff,%rax
7: c3 ret
8: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1)
f: 00 00 00
12: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
17: 89 fa mov %edi,%edx
19: be 69 19 12 28 mov $0x28121969,%esi
1e: bf ad de e1 fe mov $0xfee1dead,%edi
23: b8 a9 00 00 00 mov $0xa9,%eax
28: 0f 05 syscall
2a:* 48 3d 00 f0 ff ff cmp $0xfffffffffffff000,%rax <-- trapping instruction

The syscall is with orig %rax being 0xa9 (169 in dec). That is
the reboot system call. The problem here is that the reboot
system call calls do_exit(0) with @current being the init.

So I think the way to investigate it is take a look at kernel/reboot.c,
understand why did you end up in do_exit(0) path. Hope that helps.

--
Ammar Faizi

\
 
 \ /
  Last update: 2022-07-28 14:53    [W:0.040 / U:2.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site