lkml.org 
[lkml]   [2015]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [PATCH 4/6] x86,fpu: use disable_task_lazy_fpu_restore helper
-----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-----

\
 
 \ /
  Last update: 2015-02-02 21:21    [W:0.143 / U:9.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site