lkml.org 
[lkml]   [2017]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [tip:x86/urgent] x86/fpu: Set the xcomp_bv when we fake up a XSAVES area
From
Date
On 01/23/2017 12:28 AM, tip-bot for Kevin Hao wrote:
> x86/fpu: Set the xcomp_bv when we fake up a XSAVES area
>
> I got the following calltrace on a Apollo Lake SoC with 32-bit kernel:

...
> --- a/arch/x86/kernel/fpu/xstate.c
> +++ b/arch/x86/kernel/fpu/xstate.c
> @@ -1070,6 +1070,7 @@ int copyin_to_xsaves(const void *kbuf, const void __user *ubuf,
> * Add back in the features that came in from userspace:
> */
> xsave->header.xfeatures |= xfeatures;
> + xsave->header.xcomp_bv = XCOMP_BV_COMPACTED_FORMAT | xsave->header.xfeatures;
>
> return 0;
> }

First of all, thanks for finding this! As you found, the 32-bit XSAVES
code is a bit light on testing.

I don't doubt that we have a code path that was screwed up like this,
but I don't think this is the right fix.

The kernel xsave buffer should *ALWAYS* have the
XCOMP_BV_COMPACTED_FORMAT bit set. It should have been set before the
copyin and it should be set when it's finished.

The best fix here would be not to paper over the issue in the copy
function but find where it got clobbered, or where some initialization
code failed to set it.

\
 
 \ /
  Last update: 2017-01-23 16:36    [W:0.107 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site