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

On 8/4/2026 1:30 PM, Andrei Vagin wrote:
> 
> We can do something like this in check_xstate_in_sigframe():
> unenabled = fx_sw->xfeatures & ~fpstate->user_xfeatures;
> unenabled &= xstate_get_host_group_perm() & XFEATURE_MASK_USER_DYNAMIC;
> if (unenabled) {
>          if (xfd_enable_feature(unenabled))
>                  return false;
>          fpstate = x86_task_fpu(current)->fpstate;
> }
The inner function __xfd_enable_feature() is currently invoked from two 
spots: (1) the #NM handler on the first userspace touch of a dynamic 
state, and (2) VCPU allocation when creating an AMX-enabled VM.

For the latter, this was a chosen approach for the simplest AFAIK. Along 
with the same lines, the ptracer path deliberately does _not_ expand a 
ptracee's dynamic state.

I would expect ptrace to be the first place to adopt such an expanding 
context injection. I'm not suggesting it at all; rather, the fact that 
ptrace does not do such suggests there has been a conscious effort to 
avoid adding complexity around XFD/dynamic-state management.

Given that, it looks less convincing without first demonstrating that 
this cannot be handled in userspace. More importantly, since this would 
introduce yet another way for expanding the XSAVE buffer, it deserves 
auditing possible side-effects.

Thanks,
Chang