Re: [PATCH] Revert "x86/fpu: Refine and simplify the magic number check during signal return"
"Chang S. Bae" <[email protected]> Wed, 29 Apr 2026 10:15:18 -0700
| Newsgroups | dev.linux.lists.criu,org.kernel.vger.linux-kernel,org.kernel.vger.stable |
|---|---|
| Message-ID | <[email protected]> |
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