From: tip-bot for Oleg Nesterov <oleg@redhat.com>
To: linux-tip-commits@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, hpa@zytor.com, mingo@kernel.org,
torvalds@linux-foundation.org, jan.kratochvil@redhat.com,
tglx@linutronix.de, oleg@redhat.com, hpa@linux.intel.com
Subject: [tip:x86/urgent] i387: ptrace breaks the lazy-fpu-restore logic
Date: Mon, 16 Apr 2012 17:05:11 -0700 [thread overview]
Message-ID: <tip-089f9fba56faf33cc6dd2a6442b7ac92c58b8209@git.kernel.org> (raw)
In-Reply-To: <20120416204815.GB24884@redhat.com>
Commit-ID: 089f9fba56faf33cc6dd2a6442b7ac92c58b8209
Gitweb: http://git.kernel.org/tip/089f9fba56faf33cc6dd2a6442b7ac92c58b8209
Author: Oleg Nesterov <oleg@redhat.com>
AuthorDate: Mon, 16 Apr 2012 22:48:15 +0200
Committer: H. Peter Anvin <hpa@linux.intel.com>
CommitDate: Mon, 16 Apr 2012 16:23:59 -0700
i387: ptrace breaks the lazy-fpu-restore logic
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 <jan.kratochvil@redhat.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Link: http://lkml.kernel.org/r/20120416204815.GB24884@redhat.com
Cc: <stable@vger.kernel.org> v3.3
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
---
arch/x86/kernel/i387.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index 7734bcb..2d6e649 100644
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -235,6 +235,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;
}
prev parent reply other threads:[~2012-04-17 0:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-14 23:52 ptrace && fpu_lazy_restore Oleg Nesterov
2012-04-14 23:59 ` Oleg Nesterov
2012-04-15 2:03 ` Linus Torvalds
2012-04-15 22:38 ` Oleg Nesterov
2012-04-15 23:42 ` Linus Torvalds
2012-04-15 23:46 ` Linus Torvalds
2012-04-16 20:47 ` [PATCH 0/1] i387: ptrace breaks the lazy-fpu-restore logic Oleg Nesterov
2012-04-16 20:48 ` [PATCH 1/1] " Oleg Nesterov
2012-04-16 22:09 ` Oleg Nesterov
2012-04-17 0:05 ` tip-bot for Oleg Nesterov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=tip-089f9fba56faf33cc6dd2a6442b7ac92c58b8209@git.kernel.org \
--to=oleg@redhat.com \
--cc=hpa@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jan.kratochvil@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox