This is a note to let you know that I've just added the patch titled
i387: ptrace breaks the lazy-fpu-restore logic
to the 3.3-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:
i387-ptrace-breaks-the-lazy-fpu-restore-logic.patch
and it can be found in the queue-3.3 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.
>From 089f9fba56faf33cc6dd2a6442b7ac92c58b8209 Mon Sep 17 00:00:00 2001
From: Oleg Nesterov <[email protected]>
Date: Mon, 16 Apr 2012 22:48:15 +0200
Subject: i387: ptrace breaks the lazy-fpu-restore logic
From: Oleg Nesterov <[email protected]>
commit 089f9fba56faf33cc6dd2a6442b7ac92c58b8209 upstream.
Starting from 7e16838d "i387: support lazy restore of FPU state"
we assume that fpu_owner_task doesn't need restore_fpu_checking()
on the context switch, its FPU state should match what we already
have in the FPU on this CPU.
However, debugger can change the tracee's FPU state, in this case
we should reset fpu.last_cpu to ensure fpu_lazy_restore() can't
return true.
Change init_fpu() to do this, it is called by user_regset->set()
methods.
Reported-by: Jan Kratochvil <[email protected]>
Suggested-by: Linus Torvalds <[email protected]>
Signed-off-by: Oleg Nesterov <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: H. Peter Anvin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/i387.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -154,6 +154,7 @@ int init_fpu(struct task_struct *tsk)
if (tsk_used_math(tsk)) {
if (HAVE_HWFP && tsk == current)
unlazy_fpu(tsk);
+ tsk->thread.fpu.last_cpu = ~0;
return 0;
}
Patches currently in stable-queue which might be from [email protected] are
queue-3.3/i387-ptrace-breaks-the-lazy-fpu-restore-logic.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
