lkml.org 
[lkml]   [2017]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
Subject[PATCH] x86/fpu: set the xcomp_bv when we fake up a XSAVES area
Date
I got the following calltrace on a Apollo Lake SoC with 32bit kernel.
WARNING: CPU: 2 PID: 261 at arch/x86/include/asm/fpu/internal.h:363 fpu__restore+0x1f5/0x260
Modules linked in:
CPU: 2 PID: 261 Comm: check_hostname. Not tainted 4.10.0-rc4-next-20170120 #90
Hardware name: Intel Corp. Broxton P/NOTEBOOK, BIOS APLIRVPA.X64.0138.B35.1608091058 08/09/2016
Call Trace:
dump_stack+0x47/0x5f
__warn+0xea/0x110
? fpu__restore+0x1f5/0x260
warn_slowpath_null+0x2a/0x30
fpu__restore+0x1f5/0x260
__fpu__restore_sig+0x165/0x6b0
fpu__restore_sig+0x2f/0x50
restore_sigcontext.isra.9+0xe0/0xf0
sys_sigreturn+0xaa/0xf0
do_int80_syscall_32+0x59/0xb0
entry_INT80_32+0x2a/0x2a
EIP: 0xb77acc61
EFLAGS: 00000246 CPU: 2
EAX: 00000000 EBX: 00000003 ECX: 08151d38 EDX: 00000000
ESI: bfa9ce20 EDI: 08151d38 EBP: 0000000c ESP: bfa9cdbc
DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b

The reason is that a #GP occurs when executing XRSTORS. The root cause
is that we forget to set the xcomp_bv when we fake up the XSAVES area
in function copyin_to_xsaves().

Signed-off-by: Kevin Hao <haokexin@gmail.com>
---
arch/x86/kernel/fpu/xstate.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 35f7024aace5..2c0df2681481 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -1071,6 +1071,8 @@ int copyin_to_xsaves(const void *kbuf, const void __user *ubuf,
* Add back in the features that came in from userspace:
*/
xsave->header.xfeatures |= xfeatures;
+ xsave->header.xcomp_bv = XCOMP_BV_COMPACTED_FORMAT |
+ xsave->header.xfeatures;

return 0;
}
--
2.9.3
\
 
 \ /
  Last update: 2017-01-22 09:51    [W:1.132 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site