From: Linus Torvalds <torvalds@linux-foundation.org>
To: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: [PATCH v2 1/3] i387: fix up some fpu_counter confusion
Date: Mon, 20 Feb 2012 11:47:23 -0800 (PST) [thread overview]
Message-ID: <alpine.LFD.2.02.1202201146450.4237@i5.linux-foundation.org> (raw)
In-Reply-To: <alpine.LFD.2.02.1202201145130.4237@i5.linux-foundation.org>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mon, 20 Feb 2012 10:24:09 -0800
Subject: [PATCH v2 1/3] i387: fix up some fpu_counter confusion
This makes sure we clear the FPU usage counter for newly created tasks,
just so that we start off in a known state (for example, don't try to
preload the FPU state on the first task switch etc).
It also fixes a thinko in when we increment the fpu_counter at task
switch time, introduced by commit 34ddc81a230b ("i387: re-introduce FPU
state preloading at context switch time"). We should increment the
*new* task fpu_counter, not the old task, and only if we decide to use
that state (whether lazily or preloaded).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
That nonsensical "old->fpu_counter++" actually got the right result in
most common cases (because in the case of a preload and holding on to
the FPU for the whole timeslice - which is the normal case - it acted
the same way as if we had incremented the count at FPU load time), but
it really makes no sense.
And the "clear counters at fork time" don't really matter until you do
lazy restore, but it annoyed me that we started out a new process with
basically random fpu_counter values from the old one.
arch/x86/include/asm/i387.h | 3 ++-
arch/x86/kernel/process_32.c | 1 +
arch/x86/kernel/process_64.c | 1 +
3 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/i387.h b/arch/x86/include/asm/i387.h
index a850b4d8d14d..8df95849721d 100644
--- a/arch/x86/include/asm/i387.h
+++ b/arch/x86/include/asm/i387.h
@@ -348,10 +348,10 @@ static inline fpu_switch_t switch_fpu_prepare(struct task_struct *old, struct ta
if (__save_init_fpu(old))
fpu_lazy_state_intact(old);
__thread_clear_has_fpu(old);
- old->fpu_counter++;
/* Don't change CR0.TS if we just switch! */
if (fpu.preload) {
+ new->fpu_counter++;
__thread_set_has_fpu(new);
prefetch(new->thread.fpu.state);
} else
@@ -359,6 +359,7 @@ static inline fpu_switch_t switch_fpu_prepare(struct task_struct *old, struct ta
} else {
old->fpu_counter = 0;
if (fpu.preload) {
+ new->fpu_counter++;
if (fpu_lazy_restore(new))
fpu.preload = 0;
else
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index 80bfe1ab0031..bc32761bc27a 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -214,6 +214,7 @@ int copy_thread(unsigned long clone_flags, unsigned long sp,
task_user_gs(p) = get_user_gs(regs);
+ p->fpu_counter = 0;
p->thread.io_bitmap_ptr = NULL;
tsk = current;
err = -ENOMEM;
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 1fd94bc4279d..8ad880b3bc1c 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -286,6 +286,7 @@ int copy_thread(unsigned long clone_flags, unsigned long sp,
set_tsk_thread_flag(p, TIF_FORK);
+ p->fpu_counter = 0;
p->thread.io_bitmap_ptr = NULL;
savesegment(gs, p->thread.gsindex);
--
1.7.9.188.g12766.dirty
next prev parent reply other threads:[~2012-02-20 19:47 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-19 22:23 [PATCH 0/2] More i387 state save/restore work Linus Torvalds
2012-02-19 22:26 ` [PATCH 1/2] i387: use 'restore_fpu_checking()' directly in task switching code Linus Torvalds
2012-02-19 22:37 ` [PATCH 2/2] i387: support lazy restore of FPU state Linus Torvalds
2012-02-19 22:44 ` H. Peter Anvin
2012-02-19 23:18 ` H. Peter Anvin
2012-02-19 23:56 ` Linus Torvalds
2012-02-20 7:51 ` Ingo Molnar
2012-02-20 0:53 ` [PATCH 0/2] More i387 state save/restore work Michael Neuling
2012-02-20 1:03 ` Linus Torvalds
2012-02-20 1:06 ` Linus Torvalds
2012-02-20 1:11 ` Linus Torvalds
2012-03-01 11:30 ` Benjamin Herrenschmidt
2012-02-20 2:09 ` Indan Zupancic
2012-02-20 19:46 ` [PATCH v2 0/3] " Linus Torvalds
2012-02-20 19:47 ` Linus Torvalds [this message]
2012-02-20 19:48 ` [PATCH v2 2/3] i387: use 'restore_fpu_checking()' directly in task switching code Linus Torvalds
2012-02-20 19:48 ` [PATCH v2 3/3] i387: support lazy restore of FPU state Linus Torvalds
2012-02-21 1:50 ` Josh Boyer
2012-02-21 2:10 ` Linus Torvalds
2012-02-21 2:14 ` H. Peter Anvin
2012-02-21 5:27 ` Linus Torvalds
2012-02-21 5:35 ` H. Peter Anvin
2012-02-21 14:19 ` Josh Boyer
2012-02-21 17:59 ` H. Peter Anvin
2012-02-21 18:06 ` Ingo Molnar
2012-02-21 18:26 ` Linus Torvalds
2012-02-21 21:14 ` H. Peter Anvin
2012-02-21 21:39 ` [PATCH 0/2] i387: FP state interface cleanups Linus Torvalds
2012-02-21 21:40 ` [PATCH 1/2] i387: uninline the generic FP helpers that we expose to kernel modules Linus Torvalds
2012-02-21 21:41 ` [PATCH 2/2] i387: split up <asm/i387.h> into exported and internal interfaces Linus Torvalds
2012-02-21 23:50 ` [tip:x86/fpu] i387: Split " tip-bot for Linus Torvalds
2012-02-28 11:21 ` [PATCH 2/2] i387: split " Avi Kivity
2012-02-28 16:05 ` Linus Torvalds
2012-02-28 17:21 ` Avi Kivity
2012-02-28 17:37 ` Linus Torvalds
2012-02-28 18:08 ` Linus Torvalds
2012-02-28 18:29 ` Avi Kivity
2012-02-28 18:09 ` Avi Kivity
2012-02-28 18:34 ` Linus Torvalds
2012-02-28 19:06 ` Avi Kivity
2012-02-28 19:26 ` Linus Torvalds
2012-02-28 19:45 ` Avi Kivity
2012-02-21 23:49 ` [tip:x86/fpu] i387: Uninline the generic FP helpers that we expose to kernel modules tip-bot for Linus Torvalds
2012-02-21 2:18 ` [PATCH v2 3/3] i387: support lazy restore of FPU state Linus Torvalds
2012-02-21 2:32 ` H. Peter Anvin
2012-02-21 2:11 ` H. Peter Anvin
2012-02-21 21:54 ` Suresh Siddha
2012-02-21 21:57 ` Linus Torvalds
2012-02-21 22:19 ` Suresh Siddha
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=alpine.LFD.2.02.1202201146450.4237@i5.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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
Powered by JetHome