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. -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|