Re: [PATCH 4/8] x86/fpu: Document reasoning of FX-only fallback

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

On 8/16/2026 9:20 PM, Andrei Vagin wrote:
> Add a comment to check_xstate_in_sigframe() to explain reasoning behind
> falling back to the FX-only state when signal frame metadata is
> inconsistent.
> 
> The fallback is intended to preserve backward compatibility with legacy
> user-space processes that are not aware of XSAVE states and might only
> fill or copy just the legacy FP state.
> 
> This fallback is dangerous as it can trigger silent corruptions of

I don't think the fallback itself makes it more _dangerous_. To the 
kernel, this is one of handling options _once_ an error happens. This is 
for the better interaction with user space.

> user-space state by resetting extended registers if the process was
> using them but the frame metadata was malformed.
> 
> Reviewed-by: Alexander Mikhalitsyn <alexander@mihalicyn.com>
> Signed-off-by: Andrei Vagin <avagin@google.com>
> ---
>   arch/x86/kernel/fpu/signal.c | 8 ++++++++
>   1 file changed, 8 insertions(+)
> 
> diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c
> index 6a14b528ac7f..85021c5ea649 100644
> --- a/arch/x86/kernel/fpu/signal.c
> +++ b/arch/x86/kernel/fpu/signal.c
> @@ -54,6 +54,14 @@ static inline bool check_xstate_in_sigframe(struct fxregs_state __user *buf_fx,
>   	if (likely(magic2 == FP_XSTATE_MAGIC2))
>   		return true;
>   err_setfx:
> +	/*
> +	 * The fallback to FX-only state is used to preserve backward
> +	 * compatibility with user-space processes that are not aware of xsave
> +	 * states.
> +	 *
> +	 * In all other cases, returning false (to trigger SIGSEGV) is
> +	 * preferred to avoid silent user-space state corruption.
> +	 */
>   	trace_x86_fpu_xstate_check_failed(x86_task_fpu(current));
>   
>   	/* Set the parameters for fx only state */

With all discussions in the past, yes. I'd vote for putting such comment 
on this path. With some massage in the changelog,

   Reviewed-by: Chang S. Bae <chang.seok.bae@intel.com>

Thanks,
Chang