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

[Andrei Vagin]

On Mon, Aug 10, 2026 at 11:06 PM Chang S. Bae <chang.seok.bae@xxxxxxxxx> wrote:
>
> 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.

I agree. I think that is similar to what I suggested previously,
so it looks like we are on the same page.

>
> 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.

That sounds reasonable. I will send this series earlier next week.

Thanks,
Andrei