From: Borislav Petkov <bp@alien8.de>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Rik van Riel <riel@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Suresh Siddha <sbsiddha@gmail.com>,
linux-kernel@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
matt.fleming@intel.com, bp@suse.de, pbonzini@redhat.com,
tglx@linutronix.de, luto@amacapital.net
Subject: Re: [PATCH 1/3] x86, fpu: __kernel_fpu_begin() should clear fpu_owner_task even if use_eager_fpu()
Date: Fri, 20 Feb 2015 19:13:43 +0100 [thread overview]
Message-ID: <20150220181343.GG19378@pd.tnic> (raw)
In-Reply-To: <20150119185132.GB16427@redhat.com>
On Mon, Jan 19, 2015 at 07:51:32PM +0100, Oleg Nesterov wrote:
> __kernel_fpu_begin() does nothing if !__thread_has_fpu() && use_eager_fpu(),
> perhaps it assumes that this case is simply impossible. This is certainly
> not possible if in_interrupt() == T; interrupted_user_mode() should have
> FPU, and interrupted_kernel_fpu_idle() should fail if !__thread_has_fpu().
>
> However, even if use_eager_fpu() == T a task can do drop_fpu(), then switch
> to another thread which becomes fpu_owner_task, then resume and call some
> function which does kernel_fpu_begin(). Say, an exiting task does a lot of
> things after exit_thread(), it is not safe to assume that it can't use FPU
> in these paths.
Yap, that makes sense. Applied.
> Signed-off-by: Oleg Nesterov <oleg@redhat.com>
> ---
> arch/x86/kernel/i387.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
> index 81049ff..26f0e80 100644
> --- a/arch/x86/kernel/i387.c
> +++ b/arch/x86/kernel/i387.c
> @@ -93,9 +93,10 @@ void __kernel_fpu_begin(void)
>
> if (__thread_has_fpu(me)) {
> __save_init_fpu(me);
> - } else if (!use_eager_fpu()) {
> + } else {
> this_cpu_write(fpu_owner_task, NULL);
> - clts();
> + if (!use_eager_fpu())
> + clts();
> }
Some git archeology:
304bceda6a18 ("x86, fpu: use non-lazy fpu restore for processors supporting xsave")
added that different handling on use_eager_fpu() boxes.
interrupted_kernel_fpu_idle() failed then on those machines though and when it
was switched to
if (use_eager_fpu())
return __thread_has_fpu(current);
in
5187b28ff082 ("x86: Allow FPU to be used at interrupt time even with eagerfpu")
it forgot to correct the "else if" in __kernel_fpu_begin().
Here's the relevant hunk from 304bceda6a18:
diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index ab6a2e8028ae..528557470ddb 100644
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -22,7 +22,15 @@
/*
* Were we in an interrupt that interrupted kernel mode?
*
- * We can do a kernel_fpu_begin/end() pair *ONLY* if that
+ * For now, on xsave platforms we will return interrupted
+ * kernel FPU as not-idle. TBD: As we use non-lazy FPU restore
+ * for xsave platforms, ideally we can change the return value
+ * to something like __thread_has_fpu(current). But we need to
+ * be careful of doing __thread_clear_has_fpu() before saving
+ * the FPU etc for supporting nested uses etc. For now, take
+ * the simple route!
+ *
+ * On others, we can do a kernel_fpu_begin/end() pair *ONLY* if that
* pair does nothing at all: the thread must not have fpu (so
* that we don't try to save the FPU state), and TS must
* be set (so that the clts/stts pair does nothing that is
@@ -30,6 +38,9 @@
*/
static inline bool interrupted_kernel_fpu_idle(void)
{
+ if (use_xsave())
+ return 0;
+
return !__thread_has_fpu(current) &&
(read_cr0() & X86_CR0_TS);
}
@@ -73,7 +84,7 @@ void kernel_fpu_begin(void)
__save_init_fpu(me);
__thread_clear_has_fpu(me);
/* We do 'stts()' in kernel_fpu_end() */
- } else {
+ } else if (!use_xsave()) {
this_cpu_write(fpu_owner_task, NULL);
clts();
}
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
next prev parent reply other threads:[~2015-02-20 18:14 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-11 21:46 [RFC PATCH 0/11 BROKEN] move FPU context loading to userspace switch riel
2015-01-11 21:46 ` [RFC PATCH 01/11] x86,fpu: document the data structures a little riel
2015-01-12 21:18 ` Borislav Petkov
2015-01-12 21:38 ` Rik van Riel
2015-01-12 21:52 ` Dave Hansen
2015-01-13 15:59 ` Rik van Riel
2015-01-11 21:46 ` [RFC PATCH 02/11] x86,fpu: replace fpu_switch_t with a thread flag riel
2015-01-13 15:24 ` Oleg Nesterov
2015-01-13 16:35 ` Rik van Riel
2015-01-13 16:55 ` Oleg Nesterov
2015-01-11 21:46 ` [RFC PATCH 03/11] x86,fpu: move __thread_fpu_begin to when the task has the fpu riel
2015-01-13 15:24 ` Oleg Nesterov
2015-01-13 16:37 ` Rik van Riel
2015-01-11 21:46 ` [RFC PATCH 04/11] x86,fpu: defer FPU restore until return to userspace riel
2015-01-13 15:53 ` Oleg Nesterov
2015-01-13 17:07 ` Andy Lutomirski
2015-01-13 17:11 ` Oleg Nesterov
2015-01-13 17:18 ` Andy Lutomirski
2015-01-13 17:44 ` Rik van Riel
2015-01-13 17:57 ` Andy Lutomirski
2015-01-13 18:13 ` Rik van Riel
2015-01-13 18:26 ` Andy Lutomirski
2015-01-13 17:54 ` Rik van Riel
2015-01-13 18:22 ` Oleg Nesterov
2015-01-13 18:30 ` Oleg Nesterov
2015-01-13 20:06 ` Rik van Riel
2015-01-14 17:56 ` Oleg Nesterov
2015-01-13 17:58 ` Oleg Nesterov
2015-01-13 19:32 ` Rik van Riel
2015-01-11 21:46 ` [RFC PATCH 05/11] x86,fpu: ensure FPU state is reloaded from memory if task is traced riel
2015-01-13 16:19 ` Oleg Nesterov
2015-01-13 16:33 ` Rik van Riel
2015-01-13 16:50 ` Oleg Nesterov
2015-01-13 16:57 ` Rik van Riel
2015-01-11 21:46 ` [RFC PATCH 06/11] x86,fpu: lazily skip fpu restore with eager fpu mode, too riel
2015-01-13 17:11 ` Andy Lutomirski
2015-01-13 20:43 ` Rik van Riel
2015-01-14 18:36 ` Oleg Nesterov
2015-01-15 2:49 ` Rik van Riel
2015-01-15 19:34 ` Oleg Nesterov
2015-01-11 21:46 ` [RFC PATCH 07/11] x86,fpu: store current fpu pointer, instead of fpu_owner_task riel
2015-01-11 21:46 ` [RFC PATCH 08/11] x86,fpu: restore user FPU state lazily after __kernel_fpu_end riel
2015-01-14 18:43 ` Oleg Nesterov
2015-01-14 19:08 ` Oleg Nesterov
2015-01-11 21:46 ` [RFC PATCH 09/11] x86,fpu,kvm: keep vcpu FPU active as long as it is resident riel
2015-01-11 21:46 ` [RFC PATCH 10/11] x86,fpu: fix fpu_copy to deal with not-loaded fpu riel
2015-01-11 21:46 ` [RFC PATCH 11/11] (BROKEN) x86,fpu: broken signal handler stack setup riel
2015-01-15 19:19 ` [PATCH 0/3] x86, fpu: kernel_fpu_begin/end initial cleanups/fix Oleg Nesterov
2015-01-15 19:19 ` [PATCH 1/3] x86, fpu: introduce per-cpu "bool in_kernel_fpu" Oleg Nesterov
2015-01-16 2:22 ` Rik van Riel
2015-01-20 12:54 ` [tip:x86/fpu] x86, fpu: Introduce per-cpu in_kernel_fpu state tip-bot for Oleg Nesterov
2015-01-15 19:20 ` [PATCH 2/3] x86, fpu: don't abuse ->has_fpu in __kernel_fpu_{begin,end}() Oleg Nesterov
2015-01-16 2:27 ` Rik van Riel
2015-01-16 15:54 ` Oleg Nesterov
2015-01-16 16:07 ` Rik van Riel
2015-01-20 12:55 ` [tip:x86/fpu] x86, fpu: Don't abuse has_fpu in __kernel_fpu_begin /end() tip-bot for Oleg Nesterov
2015-01-15 19:20 ` [PATCH 3/3] x86, fpu: fix math_state_restore() race with kernel_fpu_begin() Oleg Nesterov
2015-01-16 2:30 ` Rik van Riel
2015-01-16 16:03 ` Oleg Nesterov
2015-01-20 12:55 ` [tip:x86/fpu] x86, fpu: Fix " tip-bot for Oleg Nesterov
2015-01-19 18:51 ` [PATCH 0/3] x86, fpu: more eagerfpu cleanups Oleg Nesterov
2015-01-19 18:51 ` [PATCH 1/3] x86, fpu: __kernel_fpu_begin() should clear fpu_owner_task even if use_eager_fpu() Oleg Nesterov
2015-01-20 14:15 ` Rik van Riel
2015-02-20 18:13 ` Borislav Petkov [this message]
2015-03-03 11:27 ` [tip:x86/fpu] x86/fpu: " tip-bot for Oleg Nesterov
2015-01-19 18:51 ` [PATCH 2/3] x86, fpu: always allow FPU in interrupt " Oleg Nesterov
2015-01-20 14:46 ` Rik van Riel
2015-01-20 22:46 ` Andy Lutomirski
2015-02-20 21:48 ` Borislav Petkov
2015-03-03 11:28 ` [tip:x86/fpu] x86/fpu: Always " tip-bot for Oleg Nesterov
2015-01-19 18:52 ` [PATCH 3/3] x86, fpu: don't abuse FPU in kernel threads " Oleg Nesterov
2015-01-20 14:53 ` Rik van Riel
2015-02-23 15:31 ` Borislav Petkov
2015-03-03 11:28 ` [tip:x86/fpu] x86/fpu: Don' t " tip-bot for Oleg Nesterov
2015-02-20 12:10 ` [PATCH 0/3] x86, fpu: more eagerfpu cleanups Borislav Petkov
2015-02-20 13:30 ` Oleg Nesterov
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=20150220181343.GG19378@pd.tnic \
--to=bp@alien8.de \
--cc=bp@suse.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=matt.fleming@intel.com \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=pbonzini@redhat.com \
--cc=riel@redhat.com \
--cc=sbsiddha@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.