Re: [PATCH] x86/fpu: always restore_xinit_state() when !use_eager_cpu()

[Dave Hansen]

On 04/26/2015 03:04 PM, Bobby Powers wrote:
> Oleg's commit f893959b ("x86/fpu: Don't abuse drop_init_fpu() in
> flush_thread()") removed drop_init_fpu() usage from flush_thread.
> This seems to break things for me - the Go 1.4 test suite fails all
> over the place with floating point comparision errors (offending
> commit found through bisection).

First of all, I really appreciate the bug report and the bisection.  Thanks!

Which hardware was this seen on?  Do you have any idea which part of the
test suite failed, or what actually _caused_ it to fail?

> The functional change was that flush_thread after f893959b only calls
> restore_init_xstate when both !use_eager_fpu and !used_math are true.
> drop_init_fpu (now fpu_reset_state) calls restore_init_xstate()
> regardless of whether current used_math().

This is really interesting.  We were seeing some issues where the xstate
was not getting cleared across an exec, which seemed silly, but we just
assumed it was something that had always been there.

BTW, I think restore_init_xstate() is probably buggy for the !fxsave and
softfpu cases.

> static inline void restore_init_xstate(void)
> {
>         if (use_xsave())
>                 xrstor_state(init_xstate_buf, -1);
>         else
>                 fxrstor_checking(&init_xstate_buf->i387);
> }

I'll do some testing of this today and make sure it doesn't break the
things that I saw Oleg's patch "fix".

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/