All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: dave.hansen@linux.intel.com, sbsiddha@gmail.com,
	luto@amacapital.net, tglx@linutronix.de, mingo@redhat.com,
	hpa@zytor.com, fenghua.yu@intel.com, x86@kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/6] x86,fpu: use disable_task_lazy_fpu_restore helper
Date: Mon, 02 Feb 2015 14:43:22 -0500	[thread overview]
Message-ID: <54CFD35A.8050602@redhat.com> (raw)
In-Reply-To: <20150202192139.GA17624@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/02/2015 02:21 PM, Oleg Nesterov wrote:
> I'll try to read this patch tomorrow. Too late for me.
> 
> I think it is fine, but
> 
> On 02/02, riel@redhat.com wrote:
>> 
>> This also fixes the lazy FPU restore disabling in drop_fpu,
>> which only really works when !use_eager_fpu(). ...
>> 
>> --- a/arch/x86/include/asm/fpu-internal.h +++
>> b/arch/x86/include/asm/fpu-internal.h @@ -396,7 +396,7 @@ static
>> inline void drop_fpu(struct task_struct *tsk) * Forget
>> coprocessor state.. */ preempt_disable(); -
>> tsk->thread.fpu_counter = 0; +
>> task_disable_lazy_fpu_restore(tsk); __drop_fpu(tsk); 
>> clear_used_math();
> 
> perhaps this makes sense anyway, but I am not sure if the changelog
> is right.
> 
> Note that we clear PF_USED_MATH, last_fpu/has_fpu have no effect
> after this.

There are several code paths, including signal handler stack setup and
teardown, where we first clear PF_USED_MATH, but later on set it again,
after setting up a new math state for the task.

We need to ensure we always use that new math state, and never lazily
re-use what is still in the FPU registers.

>> preempt_enable(); @@ -440,7 +440,7 @@ static inline fpu_switch_t
>> switch_fpu_prepare(struct task_struct *old, struct ta 
>> new->thread.fpu_counter > 5); if (__thread_has_fpu(old)) { if
>> (!__save_init_fpu(old)) -			old->thread.fpu.last_cpu = ~0; +
>> task_disable_lazy_fpu_restore(old); else old->thread.fpu.last_cpu
>> = cpu; old->thread.fpu.has_fpu = 0;	/* But leave fpu_owner_task!
>> */ @@ -454,7 +454,7 @@ static inline fpu_switch_t
>> switch_fpu_prepare(struct task_struct *old, struct ta stts(); }
>> else { old->thread.fpu_counter = 0; -		old->thread.fpu.last_cpu =
>> ~0; +		task_disable_lazy_fpu_restore(old);
> 
> I am also wondering if we can remove this
> task_disable_lazy_fpu_restore... I mean, perhaps we should shift
> this into __thread_fpu_end() path. But this is almost off-topic and
> in any case this patch should not do this.

Good question. I also wonder why this last_cpu = ~0 is there
anyway. If !__thread_has_fpu(old), then I don't see how the
lazy restore code would ever give a false positive on that CPU.

Either nobody else used the FPU and the task's state is still
there, or somebody else did, and the fpu_owner_task will be
pointing elsewhere.

It may be possible to simply remove this one completely, but
like you said, that should probably be a different patch.

- -- 
All rights reversed
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUz9NaAAoJEM553pKExN6DuLwH/2tUl/BZ//yjXDuv9U8PeSP9
tgqyTIuM9j36qtT9jG+iX84IDGxm1AATLXI9HQbl3KkPuAYSKo9ECnxJZO0IaDeu
vCuhtNlSnP/Fr/xe8CZ1LcWNgQBEJLINkYZn5paA5qQybsr+Z/Ll/c0/0DuGooRt
8iIGYAFHyaUJx8dkinbaaLCwP9Fg5oeXx7PAi7kpRsRtMOo1LSTZEbCTx/zIlc7L
vjz+vipQuRJxzxzwqHhE6TFpCG7c/0QiUcECoVQ13zTPAumFX23w6BSr/4llWrr9
XV0Q9vExthrcIPZynchUnsTTBGT5gVYwXL1FI3b907gFqXYDXMWPRYlXm6pneY4=
=2c6g
-----END PGP SIGNATURE-----

  reply	other threads:[~2015-02-02 19:43 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-23 19:34 question about save_xstate_sig() - WHY DOES THIS WORK? Rik van Riel
2015-01-23 20:51 ` [PATCH, RFC] x86,fpu: make signal handling xstate save & restore preemption safe Rik van Riel
2015-01-23 21:07 ` question about save_xstate_sig() - WHY DOES THIS WORK? H. Peter Anvin
2015-01-24 13:39   ` Rik van Riel
2015-01-24 20:20 ` Oleg Nesterov
2015-01-26 23:27   ` Rik van Riel
2015-01-27 19:40     ` Oleg Nesterov
2015-01-27 20:27       ` Rik van Riel
2015-01-27 20:50         ` Rik van Riel
2015-01-29 21:01           ` Oleg Nesterov
2015-01-29 20:45         ` Oleg Nesterov
2015-01-29 20:52           ` Rik van Riel
2015-01-29 21:00           ` [PATCH RFC] x86,fpu: merge save_init_fpu & unlazy_fpu Rik van Riel
2015-01-29 21:21             ` Oleg Nesterov
2015-01-29 21:07 ` [PATCH 0/3]: x86, fpu: unlazy_fpu fixes/cleanups Oleg Nesterov
2015-01-29 21:07   ` [PATCH 1/3] x86, fpu: unlazy_fpu: don't reset thread.fpu_counter Oleg Nesterov
2015-01-29 21:26     ` Rik van Riel
2015-01-29 21:08   ` [PATCH 2/3] x86, fpu: unlazy_fpu: don't do __thread_fpu_end() if use_eager_fpu() Oleg Nesterov
2015-01-29 21:36     ` Rik van Riel
2015-01-29 21:49       ` Oleg Nesterov
2015-01-29 21:53         ` Rik van Riel
2015-01-29 21:54     ` Rik van Riel
2015-01-29 21:08   ` [PATCH 3/3] x86, fpu: kill save_init_fpu(), change math_error() to use unlazy_fpu() Oleg Nesterov
2015-01-29 21:54     ` Rik van Riel
2015-01-29 21:17   ` [PATCH 0/3]: x86, fpu: unlazy_fpu fixes/cleanups Dave Hansen
2015-01-29 21:33     ` Oleg Nesterov
2015-01-29 21:43       ` Dave Hansen
2015-01-29 21:56         ` Oleg Nesterov
2015-01-29 21:58           ` Rik van Riel
2015-01-29 23:26           ` Dave Hansen
2015-01-30  1:33             ` Rik van Riel
2015-02-02 18:11               ` Dave Hansen
2015-01-30 12:45             ` Oleg Nesterov
2015-01-30 13:30               ` Oleg Nesterov
2015-01-30 13:43                 ` Oleg Nesterov
2015-01-30 17:49   ` [PATCH 0/3] cleanups to the disable lazy fpu restore code riel
2015-01-30 17:49     ` [PATCH 1/3] x86,fpu: move lazy restore functions up a few lines riel
2015-01-30 17:49     ` [PATCH 2/3] x86,fpu: introduce task_disable_lazy_fpu_restore helper riel
2015-01-30 17:49     ` [PATCH 3/3] x86,fpu: use disable_task_lazy_fpu_restore helper riel
2015-01-30 21:46       ` Dave Hansen
2015-01-30 21:48         ` Rik van Riel
2015-02-02 17:56         ` Rik van Riel
2015-02-02 18:00   ` [PATCH 0/6] cleanups to lazy FPU restore code riel
2015-02-02 18:00     ` [PATCH 1/6] x86,fpu: move lazy restore functions up a few lines riel
2015-02-02 18:00     ` [PATCH 2/6] x86,fpu: introduce task_disable_lazy_fpu_restore helper riel
2015-02-02 18:00     ` [PATCH 3/6] x86,fpu: use an explicit if/else in switch_fpu_prepare riel
2015-02-02 18:00     ` [PATCH 4/6] x86,fpu: use disable_task_lazy_fpu_restore helper riel
2015-02-02 19:21       ` Oleg Nesterov
2015-02-02 19:43         ` Rik van Riel [this message]
2015-02-03 19:08           ` Oleg Nesterov
2015-02-03 22:01             ` Rik van Riel
2015-02-06 16:42         ` Rik van Riel
2015-02-02 18:00     ` [PATCH 5/6] x86,fpu: also check fpu_lazy_restore when use_eager_fpu riel
2015-02-02 18:55       ` Oleg Nesterov
2015-02-02 19:19         ` Rik van Riel
2015-02-02 18:00     ` [PATCH 6/6] x86,fpu: remove redundant increments of fpu_counter riel
2015-02-02 18:34       ` Oleg Nesterov
2015-02-02 18:40         ` Rik van Riel
2015-02-18 23:40           ` Ingo Molnar
2015-02-18 23:54             ` Borislav Petkov
2015-02-19 20:09             ` 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=54CFD35A.8050602@redhat.com \
    --to=riel@redhat.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=sbsiddha@gmail.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 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.