Messages in this thread |  | | From | Andrei Vagin <> | | Date | Wed, 29 Apr 2026 13:44:04 -0700 | | Subject | Re: [PATCH] Revert "x86/fpu: Refine and simplify the magic number check during signal return" |
| |
On Wed, Apr 29, 2026 at 10:15 AM Chang S. Bae <chang.seok.bae@intel.com> wrote: > > 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.
Enforcing validation against 'fpstate->user_size' instead of the frame's own 'fx_sw->xstate_size' changes the kernel ABI, it isn't strengthen the sanity check logic. When user-space supplies a valid, self-consistent frame with an explicit size that older kernels accepted, and the updated logic rejects it, which triggers a userspace regression.
CRIU and gVisor breakages are not related to migration from one host to another. In both cases, they were broken even when running on the same host. Migration between different CPUs is a separate issue. In both cases, the code that constructs signal frames has existed for many years and has worked without any problem before this change.
> > > 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.
Regarding layout variations (like APX vs MPX), migration tools already track XSAVE capabilities and offsets. Furthermore, APX has its own dedicated bit in the 'xfeatures' field of the xstate_header. If platforms present conflicting layouts or incompatible extensions, CRIU cancels restoration.
The issue with checking against 'user_size' is that it disrupts migration even between compatible systems. If offsets match but the destination cpu has more features (leading to a larger 'user_size'), validation fails...
> > > 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?
Cross-host migration only works reliably between compatible systems. It works when both hosts share identical feature sets, or in a one-way direction when the target host supports all features of the source host and their XSAVE layouts are compatible. In this context, `compatible` means fpu states saved on the source hosts are restorable on the destination host.
If processes are checkpointed at safe, predefined points where they are not executing signal handlers, target host requirements can be more flexible. Here, I need to mention when CRIU constructs signal frames from userspace. In the final step, after all file descriptors and memory mappings are restored, it invokes sigreturn with a pre-constructed signal frame to restore registers and resume the fully restored process. Since CRIU constructs these frames, it can adjust the XSAVE layout if required. We currently do not do this because we have not yet seen scenarios where it would be required.
> 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.
As I mentioned, migration tools have logic to determine where a specific workload can be migrated. Because we cannot always control the exact execution point at which a process is stopped, state translation is not always feasible. For instance, an active signal frame on a process stack can be entirely outside our control. However, we can reliably find out compatible target systems where the workload can be resumed safely.
Thanks, Andrei
|  |