rpms/kernel/F-11 linux-2.6-x86-64-fix-fpu-corruption-with-signals-and-preemption.patch, NONE, 1.1 kernel.spec, 1.1574, 1.1575

[Chuck Ebbert]

Author: cebbert

Update of /cvs/pkgs/rpms/kernel/F-11
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv13293

Modified Files:
	kernel.spec 
Added Files:
	linux-2.6-x86-64-fix-fpu-corruption-with-signals-and-preemption.patch 
Log Message:
Fix possible FPU context corruption on x86-64.

linux-2.6-x86-64-fix-fpu-corruption-with-signals-and-preemption.patch:

--- NEW FILE linux-2.6-x86-64-fix-fpu-corruption-with-signals-and-preemption.patch ---
From: Suresh Siddha <suresh.b.siddha at intel.com>
Date: Thu, 9 Apr 2009 22:24:34 +0000 (-0700)
Subject: x86-64: fix FPU corruption with signals and preemption
X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=06c38d5e36b12d040839ff224e805146c0368556

x86-64: fix FPU corruption with signals and preemption

In 64bit signal delivery path, clear_used_math() was happening before saving
the current active FPU state on to the user stack for signal handling. Between
clear_used_math() and the state store on to the user stack, potentially we
can get a page fault for the user address and can block. Infact, while testing
we were hitting the might_fault() in __clear_user() which can do a schedule().

At a later point in time, we will schedule back into this process and
resume the save state (using "xsave/fxsave" instruction) which can lead
to DNA fault. And as used_math was cleared before, we will reinit the FP state
in the DNA fault and continue. This reinit will result in loosing the
FPU state of the process.

Move clear_used_math() to a point after the FPU state has been stored
onto the user stack.

This issue is present from a long time (even before the xsave changes
and the x86 merge). But it can easily be exposed in 2.6.28.x and 2.6.29.x
series because of the __clear_user() in this path, which has an explicit
__cond_resched() leading to a context switch with CONFIG_PREEMPT_VOLUNTARY.

[ Impact: fix FPU state corruption ]

Signed-off-by: Suresh Siddha <suresh.b.siddha at intel.com>
Cc: <stable at kernel.org>			[2.6.28.x, 2.6.29.x]
Signed-off-by: H. Peter Anvin <hpa at linux.intel.com>
---

diff --git a/arch/x86/kernel/xsave.c b/arch/x86/kernel/xsave.c
index 0a5b04a..c5ee17e 100644
--- a/arch/x86/kernel/xsave.c
+++ b/arch/x86/kernel/xsave.c
@@ -89,7 +89,7 @@ int save_i387_xstate(void __user *buf)
 
 	if (!used_math())
 		return 0;
-	clear_used_math(); /* trigger finit */
+
 	if (task_thread_info(tsk)->status & TS_USEDFPU) {
 		/*
 	 	 * Start with clearing the user buffer. This will present a
@@ -114,6 +114,8 @@ int save_i387_xstate(void __user *buf)
 			return -1;
 	}
 
+	clear_used_math(); /* trigger finit */
+
 	if (task_thread_info(tsk)->status & TS_XSAVE) {
 		struct _fpstate __user *fx = buf;
 		struct _xstate __user *x = buf;


Index: kernel.spec
===================================================================
RCS file: /cvs/pkgs/rpms/kernel/F-11/kernel.spec,v
retrieving revision 1.1574
retrieving revision 1.1575
diff -u -p -r1.1574 -r1.1575
--- kernel.spec	27 Apr 2009 19:30:33 -0000	1.1574
+++ kernel.spec	27 Apr 2009 21:58:34 -0000	1.1575
@@ -758,6 +758,9 @@ Patch9304: linux-2.6-xen-check-for-nx-su
 
 Patch9400: pat-remove-page-granularity-tracking-for-vm_insert_pfn_maps.patch
 
+# FPU state can become corrupt
+Patch9510: linux-2.6-x86-64-fix-fpu-corruption-with-signals-and-preemption.patch
+
 %endif
 
 BuildRoot: %{_tmppath}/kernel-%{KVERREL}-root
@@ -1403,6 +1406,8 @@ ApplyPatch linux-2.6-xen-check-for-nx-su
 
 ApplyPatch pat-remove-page-granularity-tracking-for-vm_insert_pfn_maps.patch
 
+ApplyPatch linux-2.6-x86-64-fix-fpu-corruption-with-signals-and-preemption.patch
+
 # END OF PATCH APPLICATIONS
 
 %endif
@@ -1988,6 +1993,9 @@ fi
 # and build.
 
 %changelog
+* Mon Apr 27 2009 Chuck Ebbert <cebbert at redhat.com> 2.6.29.1-113
+- Fix possible FPU context corruption on x86-64.
+
 * Mon Apr 27 2009 Kyle McMartin <kyle at redhat.com> 2.6.29.1-112
 - 7a6f9cbb: x86: hpet: fix periodic mode programming on AMD 81xx