Patch "x86/fpu: Set the xcomp_bv when we fake up a XSAVES area" has been added to the 4.9-stable tree

This is a note to let you know that I've just added the patch titled

x86/fpu: Set the xcomp_bv when we fake up a XSAVES area

to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
x86-fpu-set-the-xcomp_bv-when-we-fake-up-a-xsaves-area.patch
and it can be found in the queue-4.9 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

From: Kevin Hao <[email protected]>
Date: Sun, 22 Jan 2017 16:50:23 +0800
Subject: x86/fpu: Set the xcomp_bv when we fake up a XSAVES area

From: Kevin Hao <[email protected]>

[ Upstream commit 4c833368f0bf748d4147bf301b1f95bc8eccb3c0 ]

I got the following calltrace on a Apollo Lake SoC with 32-bit kernel:

  WARNING: CPU: 2 PID: 261 at arch/x86/include/asm/fpu/internal.h:363 fpu__restore+0x1f5/0x260
  [...]
  Hardware name: Intel Corp. Broxton P/NOTEBOOK, BIOS APLIRVPA.X64.0138.B35.1608091058 08/09/2016
  Call Trace:
   dump_stack()
   __warn()
   ? fpu__restore()
   warn_slowpath_null()
   fpu__restore()
   __fpu__restore_sig()
   fpu__restore_sig()
   restore_sigcontext.isra.9()
   sys_sigreturn()
   do_int80_syscall_32()
   entry_INT80_32()

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 the copyin_to_xsaves() function.

---
 arch/x86/kernel/fpu/xstate.c |    1 +
 1 file changed, 1 insertion(+)

@@ -1077,6 +1077,7 @@ int copyin_to_xsaves(const void *kbuf, c
 	 * 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;
 }

Patches currently in stable-queue which might be from [email protected] are

queue-4.9/x86-fpu-set-the-xcomp_bv-when-we-fake-up-a-xsaves-area.patch