Linus Torvalds Cleaned Up the Intel LAM Code for Linux 6.4 (phoronix.com) 27
Last week Linus Torvalds personally cleaned up the x86 memory copy code for Linux 6.4, Phoronix reports — and this week "he's merged more of his own code as he took issue with some of the code merged by Intel engineers as part of their Linear Address Masking enabling."
Back during the Linux 6.2 days at the end of last year, Linus rejected the Intel LAM code at the time for various technical issues. Intel then reworked it for Linux 6.4. This time around Linus merged Intel LAM into Linux 6.4 as this new CPU feature for letting user-space store metadata within some bits of pointers without masking it out before use. Intel LAM — like Arm TBI — can be of use to virtual machines, profiling / sanitizers / tagging, and other applications. But this time around there were some less than ideal code that he personally took to sprucing up...
Torvalds reworked around one hundred lines of code for cleaning it up.
It's fun to read Torvalds' commit messages (included in both Phoronix articles). Torvalds begins by writing that the LAM updates "made me unhappy about how 'access_ok()' was done, and it actually turned out to have a couple of small bugs in it too..."
Torvalds reworked around one hundred lines of code for cleaning it up.
It's fun to read Torvalds' commit messages (included in both Phoronix articles). Torvalds begins by writing that the LAM updates "made me unhappy about how 'access_ok()' was done, and it actually turned out to have a couple of small bugs in it too..."
Succession Planning? (Score:1)
Re: Succession Planning? (Score:5, Funny)
It will be an AI, based on the material of him over the years. So, a sometimes angry penguin. Eventually there will be a penguin robot embodying Linus intelligence which speaks at conferences.
Re: Succession Planning? (Score:5, Funny)
Re: (Score:2)
Re: (Score:2)
Provided he wants to. Linus almost certainly has enough money to retire whenever he feels like it, and there's nothing that says he loves his job so much that his last commit will be from hospice.
Q: What is Intel LAM? (Score:5, Interesting)
A: Intel Linear Address Masking (LAM) allows user-space applications to make use of untranslated address bits of 64-bit linear addresses for metadata. Linear addresses use either 48-bits (4-level paging) or 57-bits (5-level paging) while LAM allows the remaining space of the 64-bit linear addresses to be used for metadata. It can be of use to virtual machines, profiling / sanitizers / tagging, and other applications.
Re: (Score:2)
They've reinvented the classic Macintosh 24-bit addressing mode using the extra bits to store metadata.
I prefer the OG Torvalds (Score:1)
Re: (Score:2)
Indeed. Anything important has to be communicated in a way that gets _heard_. This is not a fluffy, bunny, we-are-all-happy-together clusterfuck, because those cannot produce quality.
Unix == memcpy() (Score:4, Interesting)
Back in the day I remember hearing the aphorism "to a first approximation, a Unix kernel is memcpy()", the reasoning being that Unix kernels spent most of their time copying memory buffers from user space to kernel space to I/O devices.
Sounds like it hasn't changed as much as one might have expected.
Re:Unix == memcpy() (Score:4, Interesting)
As a major responsibility of an OS is shoveling data between different protection domains, it is never going to change.
Typical phoronix article (Score:2)
I understand that Phoronix is clickbait for nerds, but people falling for it is totally unjustified.
Since when "Linus Torvalds wrote some code" is news? This is just a cleanup, and it's totally uninteresting. Even the fact that Linus Torvalds did it is uninteresting. Even though he is mostly a maintainer these days he still writing some code all the time, check the git logs.
Re: (Score:3)
Since when "Linus Torvalds wrote some code" is news?
Linus doesn't code much any longer; it's cool to see him step in where he feels the need. His views on Intel's work are interesting.
This place, such as it is, was founded on this sort of "news," so chill tf out.
Comment removed (Score:4, Insightful)
stupid, stupid idea (Score:3)
The programming guide for the Amiga cautioned not to use the upper 8 bits of an address for ANYTHING, because, although the MC68000 only bonded out the lower address bits, it was still a 32-bit processor and future versions might bring out all the address lines. The never-to-be-forgiven (for this among other things) clowns at Microsoft ignored the directive and used to upper address bits in their BASIC, which promptly broke everything when the 68020 (all lines bonded out) came out.
Unless someone shows some intelligence and reverts that disaster-in-the-making, we will be stuck with incompatibilities and restrictions for however long Linux/X86 lasts.
Re: (Score:3)
Couple of things, it looks like this is specifically a mode influenced by addressing mode, with one allowing for 48 bits of addressing, the other for 57 bit. So should a bigger addressing mode comes along, presumably the inappropriate LAM scheme would be disabled.
Also, as we go up in bits, the less likely we will *ever* need it. The 16MB limitation of 24 bit addressing was obviously going to come up, and the 4G of 32 bit addressing did come up... eventually though it took way longer. As we add bits we ad
Re: (Score:3)
We're at the end days of of PCIe's awkward access windows, and there is much value to disks being mapped directly to address space (and we're seeing this in specialized cases already, since it's a natural operation for NVMe).
That being said, x86 is no stranger to multiple addressing modes (even x86-64 has multiple), so the parent's concern isn't realistic.
Intel/AMD will come up with a new addressing mode when it becomes necess
Re: (Score:2)
Somewhat true, though the tricks to move the access windows around barely have a noticeable performance impact on interacting with even pcie device RAM, so it's hard to imagine that NAND access would really require superseding the traditional aperture approach. So sure, we have the address space we might as well provide the means to memory-map the whole devices even up to many many petabytes, but if there ever was a crunch for address space, it's probably easier to limit pcie to aperture approach and the s
Re: (Score:3)
But that's to be expected. The performance of any kind of access window is going to be determined on how quickly it takes you to fill it with data vs. how quickly you can modify it. If you are talking to a very slow device through the window, the cost of moving the window is not going to be a large percentage of the total cost of access.
As PCIe gets faster and faster, and the devices plugged into it do, the need to interrupt a user proces
Re: (Score:2)
x86 has multiple addressing mode. LAM works in 48-bit addressing mode.
Some future that allows bigger than 48-bit addresses (on your 64-bit pointers) will operate your code in 48-bit addressing mode, still with full LAM support. New code that needed the bigger pointers would work in a new addressing mode.
Arm64 does the same thing.
Your historical example is not analogous, because M68k made no promise that those lines would continue to be ignored in the ISA.
Re: (Score:2)
The historic example still shows that this has to be done very carefully as a special case and kept under close monitoring with regards to future changes in the hardware. Oh, and it must be easy to switch off.
Re: (Score:2)
The binary will specify whether they're allowed or not. If they are not, they will be masked.
It is the technology that allows for things like pointer-signing. It requires no kind of special monitoring with regard to future changes in the hardware, as 48/57-bit addressing is literally part of the specification.
Re: (Score:2)