linux-kernel - Re: [PATCH 4/6] x86,fpu: use disable_task_lazy_fpu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <54CFD35A.8050602@redhat.com>
Date:	Mon, 02 Feb 2015 14:43:22 -0500
From:	Rik van Riel <riel@...hat.com>
To:	Oleg Nesterov <oleg@...hat.com>
CC:	dave.hansen@...ux.intel.com, sbsiddha@...il.com,
	luto@...capital.net, tglx@...utronix.de, mingo@...hat.com,
	hpa@...or.com, fenghua.yu@...el.com, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [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@...hat.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-----
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/