Messages in this thread | | | From | Andy Lutomirski <> | Date | Mon, 25 Jan 2016 09:25:00 -0800 | 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@linux.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
| |