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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.