On 04/22/2015 05:06 PM, Yu, Fenghua wrote: > We need to copy ALL of supported xstates to user. Using xstate_bv only copies > partial xstates that are in non-init status. > > Xstate_bv only has xstates that are in non-init status. The xstates that are > in > init status will not be copied to user if using xstate_bv. In this case, the > xstates > that are in init status will be all zeros in the user buffer (remember we > clear > the user buffer before). That's incorrect.
Do we *need* to fill every field in the user buffer? I don't think that's a given. The xstate_bv that we copy out to userspace would clearly spell out which fields we've populated. Leaving the rest zeros might be OK. > So there should be a problem to use pcntxt_mask here. I'm not convinced. Let's step through this. 1. kernel does an xsaves 2. Due to the 'init optimization' xstate_bv != pcntxt_mask, and some fields of kernel xsave buffer are untouched 3. Kernel looks at pcntxt_mask, which means it copies untouched xsave buffer fields out to userspace If those untouched fields of the xsave buffer are in the "init state", then we've got no problem. But, are those "untouched since (1)" fields in the kernel xsave buf *GUARANTEED* to be in the init state? What stops this sequence of events from happening? 1. task sets xsave fields to non-init state 2. kernel 'xsaves' xsave fields to fpu.state->xsave 3. userspace gets all xsave fields to init state again 4. kernel calls 'xsaves' again, but 'xsaves' declines to fill the fpu.state->xsave fields because of the init optimization, leaves some xstate_bv bits = 0. 5. Signal handling code looks at pcntxt_mask, copies stale non-init-state fields from (2) out to userspace 6. Userspace sees wrong fields. Boom. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
