[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150509122916.GA22912@wfg-t540p.sh.intel.com>
Date: Sat, 9 May 2015 20:29:16 +0800
From: Fengguang Wu <fengguang.wu@...el.com>
To: Dave Hansen <dave.hansen@...el.com>
Cc: fengguang.wu@...el.com, Fenghua Yu <fenghua.yu@...el.com>,
LKP <lkp@...org>, linux-kernel@...r.kernel.org
Subject: [x86/xsaves] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x00000b00
Greetings,
0day kernel testing robot got the below dmesg and the first bad commit is
https://github.com/hansendc/linux.git github-mpx
commit 4d90fc49c73730c09d7afd515f9c4e08d30229bd
Author: Dave Hansen <dave.hansen@...el.com>
AuthorDate: Thu May 7 16:03:56 2015 -0700
Commit: Dave Hansen <dave.hansen@...el.com>
CommitDate: Thu May 7 16:03:56 2015 -0700
x86/xsaves: Define and use user_xstate_size for xstate size in signal context
If "xsaves" is enabled, kernel always uses compact format of xsave area.
But user space still uses standard format of xsave area. Thus, xstate size
in kernel's xsave area is smaller than xstate size in user's xsave area.
xstate in signal frame should be in standard format for user's signal
handler to access.
In no "xsaves" case, xsave area in both user space and kernel space are in
standard format. Therefore, user's and kernel's xstate sizes are equal.
In "xsaves" case, xsave area in user space is in standard format while
xsave area in kernel space is in compact format. Therefore, kernel's
xstate size is less than user's xstate size.
So here is the problem: currently kernel uses the kernel's xstate size
for xstate size in signal frame. This is not a problem in no "xsaves" case.
But it is an issue in "xsaves" case because kernel's xstate size is smaller
than user's xstate size. When setting up signal math frame in
alloc_ mathframe(), the fpstate is in standard format; but a smaller size
of fpstate buffer is allocated in signal frame for standard format
xstate. Then kernel saves only part of xstate registers into this smaller
user's fpstate buffer and user will see part of the xstate registers in
signal context. Similar issue happens after returning from signal handler:
kernel will only restore part of xstate registers from user's fpstate
buffer in signal frame.
This patch defines and uses user_xstate_size for xstate size in signal
frame. It's read from returned value in ebx from CPUID leaf 0x0D subleaf
0x0. This is maximum size required by enabled states in XCR0 and may be
enabled. This value indicates the size required for XSAVE to save all
supported user states in legacy/standard format.
And in order to copy kernel's xsave area in compact format to user xsave
area in standard format, we use copy_to_user_xstate().
Signed-off-by: Fenghua Yu <fenghua.yu@...el.com>
Reviewed-by: Dave Hansen <dave.hansen@...el.com>
+-----------------------------------------------------------+------------+------------+------------+
| | 1a745816a2 | 4d90fc49c7 | 4d90fc49c7 |
+-----------------------------------------------------------+------------+------------+------------+
| boot_successes | 114 | 31 | 31 |
| boot_failures | 9 | 83 | 83 |
| Unexpected_close,not_stopping_watchdog | 7 | 2 | 2 |
| IP-Config:Auto-configuration_of_network_failed | 2 | 2 | 2 |
| Kernel_panic-not_syncing:Attempted_to_kill_init!exitcode= | 0 | 79 | 79 |
| backtrace:do_group_exit | 0 | 79 | 79 |
| backtrace:SyS_exit_group | 0 | 79 | 79 |
+-----------------------------------------------------------+------------+------------+------------+
[ 1.092237] hostname (61) used greatest stack depth: 6960 bytes left
[ 1.093167] init[1]: segfault at 0 ip (null) sp bfaeb358 error 14 in init[80090000+2e000]
[ 1.095485] init (64) used greatest stack depth: 6888 bytes left
[ 1.096425] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000b00
[ 1.096425]
[ 1.097012] CPU: 0 PID: 1 Comm: init Not tainted 4.1.0-rc2-00025-g4d90fc4 #5
[ 1.097012] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 1.097012] d082c000 d082c000 d0837f38 cfbd6173 d0837f50 cfbd52e7 cfe04080 d082c000
[ 1.097012] cfe04080 ca5a0a00 d0837f90 cf83c75e cfd57134 00000b00 ca5b2108 b766c058
[ 1.097012] 00000000 00000001 d082c000 ca5a0a00 ca5a0a60 d0837f7c d0837f7c 00000b00
[ 1.097012] Call Trace:
[ 1.097012] [<cfbd6173>] dump_stack+0x16/0x18
[ 1.097012] [<cfbd52e7>] panic+0x7c/0x182
[ 1.097012] [<cf83c75e>] do_exit+0x8fe/0x960
[ 1.097012] [<cf83c828>] do_group_exit+0x28/0x90
[ 1.097012] [<cf83c8a1>] SyS_exit_group+0x11/0x20
[ 1.097012] [<cfbdbf19>] sysenter_do_call+0x12/0x12
[ 1.097012] Kernel Offset: 0xe800000 from 0xc1000000 (relocation range: 0xc0000000-0xd33dffff)
Elapsed time: 5
git bisect start 4d90fc49c73730c09d7afd515f9c4e08d30229bd 5ebe6afaf0057ac3eaeb98defd5456894b446d22 --
git bisect good 542e399436e980f4166ed3c25c04b0029f701f70 # 15:29 24+ 4 x86: make is_64bit_mm() widely available
git bisect good d298e33060450c01ed2889759cff4fd580aebd46 # 15:33 24+ 2 x86, mpx: do not count MPX VMAs as neighbors when unmapping
git bisect good e08ff5ad4a7d9a83e931c96384be0ebbc8e33c0c # 15:39 24+ 2 x86-fpu-xsave_kernel_buffer_compacted
git bisect good b22e8c7c585150f97945d470d3bd9dbf253730f8 # 15:43 24+ 3 x86, fpu: cleanup save_user_xstate() types
git bisect good 1a745816a2d115124ab9a47181041836c1a248f6 # 15:45 24+ 7 x86/xsave.c: Fix xstate offsets and sizes enumeration
# first bad commit: [4d90fc49c73730c09d7afd515f9c4e08d30229bd] x86/xsaves: Define and use user_xstate_size for xstate size in signal context
git bisect good 1a745816a2d115124ab9a47181041836c1a248f6 # 15:47 72+ 9 x86/xsave.c: Fix xstate offsets and sizes enumeration
# extra tests with DEBUG_INFO
git bisect bad 4d90fc49c73730c09d7afd515f9c4e08d30229bd # 15:56 0- 66 x86/xsaves: Define and use user_xstate_size for xstate size in signal context
# extra tests on HEAD of linux-devel/devel-lkp-nex05-rand-201505081410
git bisect bad 095555a8d0b69cc3e00a5675666942efab7821d0 # 15:56 0- 8 0day head guard for 'devel-lkp-nex05-rand-201505081410'
# extra tests on tree/branch hansendc/github-mpx
git bisect bad 50db9eb40ae8e9da7f8b05c78e99418946ba0f7e # 16:41 0- 16 x86/fpu: always restore_xinit_state() when !use_eager_cpu()
# extra tests on tree/branch linus/master
git bisect good af6472881a6127ad075adf64e459d2905fbc8a5c # 16:47 122+ 5 Merge branch 'for-linus-4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs
# extra tests on tree/branch next/master
git bisect good 675b3fb9606dc62afe1542b12f7b2ac3dbf753e5 # 16:50 122+ 8 Add linux-next specific files for 20150508
This script may reproduce the error.
----------------------------------------------------------------------------
#!/bin/bash
kernel=$1
initrd=quantal-core-i386.cgz
wget --no-clobber https://github.com/fengguang/reproduce-kernel-bug/raw/master/initrd/$initrd
kvm=(
qemu-system-x86_64
-enable-kvm
-cpu kvm64
-kernel $kernel
-initrd $initrd
-m 300
-smp 2
-device e1000,netdev=net0
-netdev user,id=net0
-boot order=nc
-no-reboot
-watchdog i6300esb
-rtc base=localtime
-serial stdio
-display none
-monitor null
)
append=(
hung_task_panic=1
earlyprintk=ttyS0,115200
systemd.log_level=err
debug
apic=debug
sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100
panic=-1
softlockup_panic=1
nmi_watchdog=panic
oops=panic
load_ramdisk=2
prompt_ramdisk=0
console=ttyS0,115200
console=tty0
vga=normal
root=/dev/ram0
rw
drbd.minor_count=8
)
"${kvm[@]}" --append "${append[*]}"
----------------------------------------------------------------------------
Thanks,
Fengguang
View attachment "dmesg-quantal-ivb41-100:20150508233632:i386-randconfig-nexr1-0505:4.1.0-rc2-00025-g4d90fc4:5" of type "text/plain" (44348 bytes)
View attachment "config-4.1.0-rc2-00025-g4d90fc4" of type "text/plain" (75512 bytes)
Powered by blists - more mailing lists