AMD’s August 21 UALink submission has already been revised. The August 31 version describes pinned exported memory, correcting the earlier explanation built around movable allocations. The code is a proposal for review, not proof of support in every Linux distribution.
What the revised series says
The 95-patch v2 cover letter describes core infrastructure and AMDGPU integration for UALoE, UALink over Ethernet. A separate three-patch series covers the application interface and documentation. Keeping those roles separate makes the patch count more informative than treating it as one giant feature switch.
The updated documentation explicitly says exported memory is pinned. Remote translation invalidations remove access when that memory is freed. The earlier description of evictions moving exported allocations does not match this revision. The first series conditionally disables its proposed sysfs configuration interface, with removal planned and out-of-band configuration tooling intended initially.
An address is not permission to use all memory
The proposal divides a Network Physical Address space between GPUs. A buffer owner exports an allocation and obtains an opaque handle. An authorized importer uses that handle to create a local reference to the remote allocation. The existence of a shared address space does not mean every process can read every GPU's memory.
For an original explanation, imagine GPU A holding buffers X and Y while GPU B is permitted to import X. Sharing X's handle should not be described as granting B access to Y. When X is released, B's earlier reference must not continue granting access to storage that may acquire a different purpose. That is why lifetime and invalidation matter alongside link bandwidth.
This example explains the ownership relationship; it is not a test of the proposed authorization mechanism or a physical layout of an AMD rack.
Avoid the Ethernet versus memory shortcut
The proposal itself uses Ethernet as the underlying transport while exposing a scale-up remote-memory operation. It therefore contradicts a blanket claim that Ethernet necessarily means only explicit application message passing. Link technology, transport semantics and the interface visible to a program are different levels of description.
Direct remote loads and stores also do not mean that communication is free or that no data travels. They describe how the access is expressed, not zero latency or an absence of traffic.
For deployment planning, look for accepted kernel code, the matching user-space runtime, platform support and documented configuration. Posting or revising a series supplies reviewable implementation details; it does not by itself commit Linux 7.4 or any other release to shipping them.
Update to August 31 v2: exported memory is pinned, remote invalidations occur on release, and initial sysfs configuration was disabled pending removal. Do not promise a merge.