[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrVjt3qcbrBa5BQ36ieQtL=JCwy_0n1JvF+tvLV0FVE-wg@mail.gmail.com>
Date: Mon, 25 Jan 2016 09:25:00 -0800
From: Andy Lutomirski <luto@...capital.net>
To: Dave Hansen <dave.hansen@...ux.intel.com>
Cc: Yu-cheng Yu <yu-cheng.yu@...el.com>,
Fenghua Yu <fenghua.yu@...el.com>,
Borislav Petkov <bp@...en8.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Oleg Nesterov <oleg@...hat.com>,
Sai Praneeth Prakhya <sai.praneeth.prakhya@...el.com>,
X86 ML <x86@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Rik van Riel <riel@...hat.com>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v2 2/5] x86/fpu: Fix FNSAVE usage in eagerfpu mode
On Jan 25, 2016 7:41 AM, "Dave Hansen" <dave.hansen@...ux.intel.com> wrote:
>
> On 01/24/2016 02:38 PM, Andy Lutomirski wrote:
> > if (fpu->fpregs_active) {
> > + /*
> > + * Ignore return value -- we don't care if reg state
> > + * is clobbered.
> > + */
> > copy_fpregs_to_fpstate(fpu);
> > } else {
> > this_cpu_write(fpu_fpregs_owner_ctx, NULL);
> > @@ -189,8 +193,12 @@ void fpu__save(struct fpu *fpu)
> >
> > preempt_disable();
> > if (fpu->fpregs_active) {
> > - if (!copy_fpregs_to_fpstate(fpu))
> > - fpregs_deactivate(fpu);
> > + if (!copy_fpregs_to_fpstate(fpu)) {
> > + if (use_eager_fpu())
> > + copy_kernel_to_fpregs(&fpu->state);
> > + else
> > + fpregs_deactivate(fpu);
> > + }
> > }
> > preempt_enable();
>
> I wonder if we should just make the
>
> > + if (use_eager_fpu())
> > + copy_kernel_to_fpregs(&fpu->state);
> > + else
> > + fpregs_deactivate(fpu);
>
> behavior the default _inside_ copy_fpregs_to_fpstate(fpu). We evidently
> got it wrong in 2/3 of the call sites that needed it. It ends up being
> an optimization for FNSAVE (because it allows us to avoid an FRSTOR),
> but we only take advantage of that in cases of kernel_fpu_begin/end().
>
> FXSAVE has been around since at _least_ 1999, and I'd expect it to get
> used in place of FNSAVE everywhere that it is available.
>
> If we don't want to do that, maybe we should add a "clobber" argument to
> copy_fpregs_to_fpstate() for when it's allowed to clobber the register
> state.
>
> I just hate putting this logic at all the call sites.
Me too. I was thinking about having a clobber and a non-clobber variant.
The tricky part is that we have to think about preemption, too. In
theory, copying fpregs to somewhere other then the normal spot can be
okay with preemption on except in the FNSAVE case, but all the callers
probably need preemption off anyway.
Even if we do the cleanup, I think I'd rather fix the bug in place
first so the diff is clearer and then clean it up on top of that.
Does that seem reasonable?
--Andy
Powered by blists - more mailing lists