mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Chang S. Bae" <chang.seok.bae@intel.com>
To: Andrei Vagin <avagin@google.com>,
	Thomas Gleixner <tglx@kernel.org>,
	"Ingo Molnar" <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>
Cc: <linux-kernel@vger.kernel.org>, <criu@lists.linux.dev>,
	Dave Hansen <dave.hansen@linux.intel.com>, <x86@kernel.org>,
	Alexander Mikhalitsyn <alexander@mihalicyn.com>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH 3/8] x86/fpu: Split __fpu_restore_sig to extract compat path
Date: Wed, 2 Sep 2026 14:15:24 -0700	[thread overview]
Message-ID: <2c480c94-a996-4252-b9ba-be5145cfe69f@intel.com> (raw)
In-Reply-To: <20260817042048.1579415-4-avagin@google.com>

On 8/16/2026 9:20 PM, Andrei Vagin wrote:
> Split __fpu_restore_sig to move the restore part for the legacy/compat
> FPU state (when buf_f is present) to a separate helper function.

Not sure where the justification for this refactoring is. Is this 
primarily preparation for the next change?

> 
> The legacy 32-bit FP frame duplicates the FP state portion of the
> FX/XSAVE frame. For backward compatibility, the legacy FP frame is
> treated as the source of truth, and its state is folded into the
> FX/XSAVE state before restoring the registers.

This reads more like a description of what the refactored code has 
already been doing than a motivation of the change itself.

> diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c
> index 42c3d78bd849..6a14b528ac7f 100644
> --- a/arch/x86/kernel/fpu/signal.c
> +++ b/arch/x86/kernel/fpu/signal.c
> @@ -264,6 +264,9 @@ static int __restore_fpregs_from_user(void __user *buf, u64 task_xfeatures,
>   	}
>   }
>   
> +static bool restore_fpregs_from_user_compat(void __user *buf_f, void __user *buf_fx,
> +					    u64 xrestore_mask, bool fx_only);
> +
>   /*
>    * Attempt to restore the FPU registers directly from user memory.
>    * Pagefaults are handled and any errors returned are fatal.
> @@ -324,14 +327,9 @@ static bool restore_fpregs_from_user(void __user *buf, u64 xrestore_mask, bool f
>   	return true;
>   }
>   
> -static bool __fpu_restore_sig(void __user *buf_f, void __user *buf_fx,
> -			      bool ia32_fxstate)
> +static bool __fpu_restore_sig(void __user *buf_f, void __user *buf_fx)
>   {
> -	struct task_struct *tsk = current;
> -	struct fpu *fpu = x86_task_fpu(tsk);
> -	struct user_i387_ia32_struct env;
> -	bool success, fx_only = false;
> -	union fpregs_state *fpregs;
> +	bool fx_only = false;
>   	u64 xrestore_mask = 0;
>   
>   	if (use_xsave()) {
> @@ -346,11 +344,33 @@ static bool __fpu_restore_sig(void __user *buf_f, void __user *buf_fx,
>   		xrestore_mask = XFEATURE_MASK_FPSSE;
>   	}
>   
> -	if (likely(!ia32_fxstate)) {
> +	if (likely(!buf_f)) {
>   		/* Restore the FPU registers directly from user memory. */
>   		return restore_fpregs_from_user(buf_fx, xrestore_mask, fx_only);
>   	}
>   
> +	return restore_fpregs_from_user_compat(buf_f, buf_fx, xrestore_mask, fx_only);
> +}

I don't think replacing `ia32_fxstate` with `buf_f` is a clear win for 
description itself.

Furthermore, __fpu_restore_sig() now looks thin enough that this may not 
need to remain. It could be folded into fpu_restore_sig() rather than 
tweaking the argument naming, then. I assume the resulting 
fpu_restore_sig() does not become too messy.

Thanks,
Chang

  reply	other threads:[~2026-09-02 21:15 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-17  4:20 [PATCH v4 0/8] x86/fpu: Restore and reinforce signal frame portability Andrei Vagin
2026-08-17  4:20 ` [PATCH 1/8] x86/fpu: Document " Andrei Vagin
2026-09-02 21:15   ` Chang S. Bae
2026-09-03  4:51   ` Borislav Petkov
2026-08-17  4:20 ` [PATCH 2/8] x86/fpu: Clean up and rename variables in signal frame handling Andrei Vagin
2026-08-17  4:20 ` [PATCH 3/8] x86/fpu: Split __fpu_restore_sig to extract compat path Andrei Vagin
2026-09-02 21:15   ` Chang S. Bae [this message]
2026-08-17  4:20 ` [PATCH 4/8] x86/fpu: Document reasoning of FX-only fallback Andrei Vagin
2026-09-02 21:15   ` Chang S. Bae
2026-08-17  4:20 ` [PATCH 5/8] selftests/x86: Add a test for signal frame FPU portability Andrei Vagin
2026-08-17  4:20 ` [PATCH 6/8] x86/fpu: Fix potential underflow in xstate_calculate_size() Andrei Vagin
2026-09-02 21:15   ` Chang S. Bae
2026-08-17  4:20 ` [PATCH 7/8] x86/fpu: Pre-fault only required size of xstate buffer Andrei Vagin
2026-09-02 21:15   ` Chang S. Bae
2026-08-17  4:20 ` [PATCH 8/8] selftests/x86: Add a sigframe insufficient xstate_size test Andrei Vagin
2026-09-02 21:16   ` Chang S. Bae

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2c480c94-a996-4252-b9ba-be5145cfe69f@intel.com \
    --to=chang.seok.bae@intel.com \
    --cc=alexander@mihalicyn.com \
    --cc=avagin@google.com \
    --cc=bp@alien8.de \
    --cc=criu@lists.linux.dev \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®