Why Intel’s Linear Address Masking (LAM) Was Rejected from Linux 6.2

Intel hopes to merge its Linear Address Masking (LAM) feature into Linux 6.2, but Linus Torvalds criticized the patch and rejected the merge.

Intel LAM allows software to use the unused high bits of a 64‑bit linear address for metadata. While typical linear addresses use 48 bits (4‑level paging) or 57 bits (5‑level paging), LAM exploits the remaining bits for purposes such as memory reclamation and tagging, similar to AMD’s Upper Address Ignore (UAI) and ARM’s Top‑Bits‑Ignore (TBI) features.

Intel first demonstrated LAM in early 2020 and has been working on Linux kernel support since then. In mid‑November, Intel engineers submitted many patches to the x86/mm branch of Linux 6.2, aiming to integrate the feature.

Linus demanded that Intel rename the LAM feature to “Top‑Bits‑Ignore” (TBI) and expressed strong dissatisfaction with both the implementation and the name. The LAM functionality is not limited to the mm subsystem; it could affect every thread. Imagine a scenario where some threads use tagged pointers while others do not, allowing high‑order address bits to carry VM‑specific tags or enable a “native” mode that sees the full address space. Such virtual‑address masking could enable not only memory reclamation but also genuine isolation (e.g., JIT‑generated code accessing only low bits while the JITter sees the full address space). Although this may not reflect how LAM works on x86, the changes to untagged_addr() are not x86‑specific. The specific mm‑focused LAM code is likely to become an active bug in the kernel, even on x86‑64. Therefore, the author believes LAM is a fundamental design mistake; despite resolving minor conflicts, the feature was pulled because its design is flawed.

Linux kernel mailing list discussions highlighted design concerns, and Linus concluded that Intel’s LAM code was not ready for Linux, so the patches were not merged. Intel has submitted a new x86/mm pull request that removes the LAM code, and Intel Linux engineers plan to rewrite the feature for Linux 6.3.

Kernel mailing list thread 1

Kernel mailing list thread 2