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

On 8/8/2026 11:50 AM, Andrei Vagin wrote:
> 
> If we decide not to enable dynamic features when restoring state from a
> signal frame:
> 
> diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c
> index 083f03d2d002..e2eeb85cc0cd 100644
> --- a/arch/x86/kernel/fpu/signal.c
> +++ b/arch/x86/kernel/fpu/signal.c
> @@ -64,6 +64,9 @@ static inline bool check_xstate_in_sigframe(struct
> fxregs_state __user *buf_fx,
>          if (unlikely(magic2 != FP_XSTATE_MAGIC2))
>                  goto err_setfx;
> 
> +       if ((fx_sw->xfeatures & XFEATURE_MASK_USER_DYNAMIC) &
> ~fpstate->user_xfeatures)
> +               return false;
> +
>          if (fx_sw->xstate_size != fpstate->user_size ||
>              fx_sw->xfeatures != fpstate->user_xfeatures) {
>                  unsigned int xsize;
> 
> 
> Then when a process is restored, we need to re-enable all dynamic
> features that were enabled at the time of dump (restoring
> fpstate->user_xfeatures per thread).
> 
> However, ARCH_GET_XCOMP_PERM only gives us the mask of permitted
> features for the process, not what is actually enabled for each thread.
> We could blindly enable all permitted features on all threads, but that
> is not ideal.
Couldn't be staged for the review?

  (1) First, the above change with this patch
      * This can establish the semantic - reject from restoring a signal
        frame with dynamic state if not enabled (not first-touched).
      * A checkpoint program would need to make the required dynamic
        features available for every thread. While suboptimal, migration
        would be possible then.
  (2) Then, follow on with further optimizations, potentially including
      the new arch_prctl proposal

This would make the two approaches distinguishable and give a chance to 
compare the implementation complexity and costs.

Then, since these last two patches grow more, it could be an option to 
split the series: the patches before this could be relatively 
straightforward, while the more debatable changes could follow on later.

Thanks,
Chang