From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933440AbbBBTnl (ORCPT ); Mon, 2 Feb 2015 14:43:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60443 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932946AbbBBTnk (ORCPT ); Mon, 2 Feb 2015 14:43:40 -0500 Message-ID: <54CFD35A.8050602@redhat.com> Date: Mon, 02 Feb 2015 14:43:22 -0500 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Oleg Nesterov 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 References: <20150129210723.GA31584@redhat.com> <1422900051-10778-1-git-send-email-riel@redhat.com> <1422900051-10778-5-git-send-email-riel@redhat.com> <20150202192139.GA17624@redhat.com> In-Reply-To: <20150202192139.GA17624@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org -----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-----