Intel wants to make its LAM (Linear Address Masking:linear address mask) functionality is incorporated into the Linux 6.2, but the feature was criticized by Linus and rejected the merge.

Intel Linear Address Mask (LAM) allows software to use the untranslated address bits of 64-bit linear addresses for metadata, linear addresses use 48 bits (4-level paging) or 57 bits (5-level paging), and LAM allows The remainder of the linear address space is used for metadata.

In short, Intel LAM is using the untranslated address bits of userspace addresses, so it can be used for multiple purposes for metadata such as userspace memory cleanup and marking, it’s essentially similar to AMD’s high address ignore “UAI” (Upper Address Ignore) and Arm’s top byte ignore “TBI” (Top-Bits-Ignore) function.

Intel first demonstrated LAM in 2020 and has been working on Linux kernel support since then. In mid-November, Intel engineers submitted a large number of patches for the x86/mm branch of Linux 6.2, hoping to incorporate the functional code into the kernel.

However, LAM was immediately criticized by Linus, not only the kernel implementation code, but Linus was even dissatisfied with the name “LAM”:

Is it too late to ask Intel to call this LAM feature “Top-Bits-Ignore” (TBI)?

…

The whole LAM functionality is not mm specific, it can easily affect each thread.

Imagine having a setup where some threads use tagged pointers and some don’t. For example, the upper bits of the address might contain a tag that is only used in the virtual machine, or even let the “native” mode use the full address space and put itself and private data virtually in the upper bits.

Also imagine using a virtual address mask to implement not just a memory cleaner, but a true separation of functionality (e.g. the JITed code might basically only have access to the lower bits, while the JITter itself sees the entire address space ).

Maybe that’s not how LAM works on x86, but its change to untagged_addr() isn’t x86 specific.so i really think it’scompletely wrong, it’s all about some invalid assumptions, except for the naming. In fact, this mm-specific LAM function,It will only end up being an active bug in the code even on x86-64.

So I really think LAM is a fundamental design error, and while I pulled it and resolved trivial conflicts, I pulled it again because it was wrong by design.

The Linux kernel mailing list discusses design changes to Intel’s Linux implementation of LAM. But Linus felt that the Intel LAM code was not yet ready for Linux, so the code was not merged in the end. Intel has submitted a new x86/mm pull with the LAM code removed. Intel Linux engineers will be rewriting the LAM code in preparation for Linux 6.3.