[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrVm1ZygpEz+912BcMgTAPznB24uYsB1yQ_V4YQa2N-DzQ@mail.gmail.com>
Date: Fri, 12 Oct 2018 11:07:28 -0700
From: Andy Lutomirski <luto@...nel.org>
To: Dave Hansen <dave.hansen@...ux.intel.com>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
Andrew Lutomirski <luto@...nel.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Radim Krcmar <rkrcmar@...hat.com>,
kvm list <kvm@...r.kernel.org>,
"Jason A. Donenfeld" <Jason@...c4.com>,
Rik van Riel <riel@...riel.com>
Subject: Re: [PATCH 07/11] x86/pkeys: Drop the preempt-disable section
On Fri, Oct 12, 2018 at 10:58 AM Dave Hansen
<dave.hansen@...ux.intel.com> wrote:
>
> On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote:
> > The fpu->initialized flag should not be changed underneath us. This might be a
> > fallout during the removal of the LazyFPU support. The FPU is marked
> > initialized as soon as the state has been set to an initial value. It does not
> > signal if the CPU's FPU registers are loaded.
>
> If this is true, then the check for fpu->initialized should also go away.
>
All these "if" statements in the FPU code are messy and make
understanding and reviewing this code hard.
Can you prepare a patch for the beginning of your series that removes
fpu->initialized and just ensures that the fpu is always initialized?
This will regress performance, but you should get all that performance
back with TIF_LOAD_FPU.
Powered by blists - more mailing lists