November 29, 2023

PBX Science

VoIP & PBX, Networking, DIY, Computers.

Features that were criticized by name by Linus have now been merged into Linux 6.4

3 min read

Features that were criticized by name by Linus have now been merged into Linux 6.4

 

Features that were criticized by name by Linus have now been merged into Linux 6.4.

The Intel LAM (Linear Address Masking) function, which was criticized by Linus , was finally merged into Linux 6.4.

Intel’s Linear Address Mask (LAM) allows software to use the untranslated address bits of a 64-bit linear address for metadata, and can be used for a variety of metadata purposes such as userspace memory scrubbing and tagging.

It is essentially similar to AMD’s high address ignore “UAI” (Upper Address Ignore) and Arm’s top byte ignore “TBI” (Top-Bits-Ignore) function.

 

Features that were criticized by name by Linus have now been merged into Linux 6.4

 

Intel first demonstrated LAM to the public in 2020, and has since been working on providing it with Linux kernel support. Intel LAM was originally submitted to the Linux 6.2 merge window, but was then severely criticized by Linus, from name to functional design.

After the code was improved, the LAM support code was again shipped to the Linux 6.4 merge window as part of x86/mm. Linus Torvalds did the merge on Friday , pulling in the LAM-enabling code submitted by Intel engineers (although Linus personally still doesn’t like the name of the feature).

This time Linus didn’t raise any fundamental objections to LAM’s code, but he ended up writing a new patch himself to make access_ok() independent of LAM because he didn’t like the design.

 

 

Previouse News on Dec 20, 2022


Linus criticizes Intel’s LAM code, refuses to merge it into kernel

Intel wanted to merge its LAM ( Linear Address Masking: linear address mask) function into Linux 6.2, but this function was criticized by Linus and rejected the merger.

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 merge 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, and it is even possible to have “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 only a memory cleaner, but a true separation of functionality (e.g. JITed code may 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’s just plain wrong , and it’s all some invalid assumptions aside from the naming. In fact, this mm-specific LAM feature ends 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.


Copyright © All rights reserved. | Newsphere by AF themes.