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
next prev parent 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®