Re: [PATCH 09/10] x86/fpu: Allow restoring signal frames with larger xstate_size

["Chang S. Bae" <chang.seok.bae@intel.com>]

On 6/15/2026 12:37 PM, Andrei Vagin wrote:
> The kernel previously enforced that the xstate_size in the signal frame
> must not exceed the current task's fpstate->user_size. This prevents
> restoring signal frames that were saved on another CPU (in case of
> container/process migration) with a different (larger) set of enabled
> xstate features, even if the features to be restored are compatible.
> 
> Relax this restriction by removing the strict check against user_size.
> The previous commit introduced infrastructure to calculate the actual
> required size based on the intersection of requested and supported
> features.  We now rely on that validation and only require that the
> provided xstate_size is sufficient for the active features.

I appreciate the effort to document the contract, add regression tests, 
and tighten the validation logic along with the revert fix so far in 
this series.

But I'm wondering this bit of relaxing the checker is really necessary 
at this point.

With APX, userspace can no longer assume that a higher XSTATE component 
number implies a higher offset within the XSAVE image. Going forward, 
migration software will likely need a more robust approach that 
interprets the layout and transforms the image when moving between 
machines with different layouts. With such translation, maybe further 
relaxing the kernel-side checker isn't that needed.

Thanks,
Chang