From: "Chang S. Bae" <chang.seok.bae@intel.com>
To: Andrei Vagin <avagin@gmail.com>
Cc: Andrei Vagin <avagin@google.com>,
Thomas Gleixner <tglx@kernel.org>,
"Ingo Molnar" <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
<linux-kernel@vger.kernel.org>, <criu@lists.linux.dev>,
<x86@kernel.org>, <stable@vger.kernel.org>
Subject: Re: [PATCH] Revert "x86/fpu: Refine and simplify the magic number check during signal return"
Date: Wed, 29 Apr 2026 10:15:18 -0700 [thread overview]
Message-ID: <3ef742fe-9761-4714-84d9-e72fabc5def1@intel.com> (raw)
In-Reply-To: <CANaxB-xvGc1A3Ga_ASh-RZbh0+abxp4e4qbiPKcMJ5-5Wtzr6Q@mail.gmail.com>
On 4/29/2026 9:44 AM, Andrei Vagin wrote:
>
> First of all, the reverted change broke backward compatibility for
> user-space.
The ABI itself is still intact. Do you mean that the kernel cannot
strengthen its sanity check logic? The change does not alter the ABI,
but enforces stricter validation of the existing format.
> As for layout compatibility, in most cases CPU A (older) and CPU B
> (newer) have compatible XSAVE layouts in terms of saving states on A
> and restoring them on B. CPU B may feature new extended hardware
> states, but the layout for previously supported components remains
> the same.
I don't think this assumption holds. For example, with APX, the state is
placed at the offset previously used by MPX. So the layout is not
strictly append-only, and offsets are not guaranteed to remain stable
across different CPU generations.
> Even if CRIU were somehow able to locate these frames, extending
> them would be impossible. The target application stack is not
> under our control, and other user stack data or local variables
> reside immediately after the frame.
I’m confused by this point. If the frame cannot be adjusted, in the
first place, how does migration work across systems with differing
feature sets?
Features can be introduced or deprecated over time, and a snapshot taken
on one machine cannot be expected to run unmodified on an random machine
with a different XSTATE set. Some form of translation is inevitable for
any cross-machine restore mechanism.
Thanks,
Chang
next prev parent reply other threads:[~2026-04-29 17:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-29 0:06 [PATCH] Revert "x86/fpu: Refine and simplify the magic number check during signal return" Andrei Vagin
2026-04-29 7:26 ` Chang S. Bae
2026-04-29 16:44 ` Andrei Vagin
2026-04-29 17:15 ` Chang S. Bae [this message]
2026-04-29 20:44 ` Andrei Vagin
2026-04-29 21:44 ` Chang S. Bae
2026-04-30 0:28 ` Andrei Vagin
2026-05-01 18:44 ` Andrei Vagin
2026-05-01 19:13 ` Chang S. Bae
2026-05-01 20:50 ` Andrei Vagin
2026-05-01 21:04 ` Chang S. Bae
2026-05-01 21:42 ` Andrei Vagin
2026-05-02 19:23 ` 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=3ef742fe-9761-4714-84d9-e72fabc5def1@intel.com \
--to=chang.seok.bae@intel.com \
--cc=avagin@gmail.com \
--cc=avagin@google.com \
--cc=bp@alien8.de \
--cc=criu@lists.linux.dev \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=stable@vger.kernel.org \
--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