Zack's Kernel News
Cleaning asm Out of syscall Slow-Path Selection Code
Linus Torvalds pointed out an issue with the x86-64 and 32-bit system call code. He said the code that chose which slow path to execute for any given system call was a mish-mash nightmare of Frankensteinian proportions, mixing assembler code with C code in complex ways that were vile and grotesque.
He posted some code that laid the groundwork for one day replacing the whole mess with crisp, clean C code. He remarked, "I didn't bother trying to clean up the 32-bit code similarly (no test-cases, and trust me, if you get this wrong, it will fail spectacularly but in very subtle and hard-to-debug ways)." He added that his code "is actually tested, and seems to work (including limited testing with strace, gdb etc), and while it adds a few more lines than it removes, the removed lines are mostly asm, and added lines are C."
His vision for the future of this particular batch of code, he said, was to address each case of assembler code one by one, until they were all replaced with calls to a single wrapper function. Then, that wrapper function could be replaced with some well-written C code.
Al Viro pointed out some additional technical issues; in particular, he pointed out some problems they should expect to encounter when porting these changes to 32-bit kernels. Linus remarked, "Yes, the 32-bit code I didn't want to touch, partly because I no longer have a test-case. And it does end up having some more interesting cases."
H. Peter Anvin was very excited to see Linus working on this. He said, "this code is incredibly ugly and getting it cleaned up would really, really help, of course." Peter Zijlstra said he also was thrilled that Linus was doing this stuff. He said, "its a nice cleanup, entry.S always hurts my brain."
Al continued pointing out deep assembler horrors and trying to indicate ways to fix them. He, Linus, Andy Lutomirski, and others discussed the technical details. Part of the difficulty remained the open question of exactly how much to even bother trying to fix versus the quantity of soul-death each portion of such fixes would cause.
At one point (to give a semi-readable example of the conversation), Al said, "The problem with validation is that we'll suddenly become sensitive to hard-to-estimate pile of hardware bugs ;-/ E.g. which AMD-specific errata is that comment in entry_64.S about? The one I kinda-sorta remember is Intel-specific, and that was about uncanonical RIP; looking for AMD one has turned #353 (with suggested workaround being 'have bit 16 set in whatever you put into R11'), but I've no idea whether that's the only potential issue there … ."
The discussion went on for a bit and was inscrutably technical. The difficulties of eradicating assembly language from the Linux kernel seem to be immense. Ultimately, Linus, Al, and the rest will probably not try to get rid of assembler code absolutely everywhere. In some cases, the speed advantage of assembly language is highly significant, and other cases involve initialization code that occurs very early in the boot process, where very specific opcodes are expected and required.
The whole issue is reminiscent of the effort to get rid of the Big Kernel Lock (BKL) some years back. In that case, it had proven extremely difficult even to approach the problem. The BKL was everywhere! Rewriting it to be smaller, sleeker, and more targeted was simply not possible with things as they stood.
The solution ended up being to push the BKL code outward from where it was defined and duplicate that code wherever it might be needed, instead of keeping it as a single centralized function call. That project alone proved time consuming and difficult. Once the BKL had been thoroughly distributed, however, each separate case could be examined and recoded to perform only the locking behavior that was actually needed. In many cases, the desired locks were simple and could be reimplemented as a new semaphore or similar type of lock that could be called from diverse portions of the kernel. But, as more and more occurrences of the BKL were replaced in this way, the remaining cases proved more and more difficult; and so, it was years before the last of them could be rooted out and recoded with specialized locking mechanisms that met the particular needs of those parts of the kernel.
The current situation with assembler in the syscall slow-path selection code is similar. Linus wants to address the easy cases consistently and get them out of the way, then tackle the progressively more difficult cases as folks identify possible solutions for them. But, as with the BKL, it seems as if this may turn out to be a long slog.
Zack Brown
The Linux kernel mailing list comprises the core of Linux development activities. Traffic volumes are immense, often reaching 10,000 messages in a week, and keeping up to date with the entire scope of development is a virtually impossible task for one person. One of the few brave souls to take on this task is Zack Brown.
« Previous 1 2
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.
News
-
Fedora 39 Beta is Now Available for Testing
For fans and users of Fedora Linux, the first beta of release 39 is now available, which is a minor upgrade but does include GNOME 45.
-
Fedora Linux 40 to Drop X11 for KDE Plasma
When Fedora 40 arrives in 2024, there will be a few big changes coming, especially for the KDE Plasma option.
-
Real-Time Ubuntu Available in AWS Marketplace
Anyone looking for a Linux distribution for real-time processing could do a whole lot worse than Real-Time Ubuntu.
-
KSMBD Finally Reaches a Stable State
For those who've been looking forward to the first release of KSMBD, after two years it's no longer considered experimental.
-
Nitrux 3.0.0 Has Been Released
The latest version of Nitrux brings plenty of innovation and fresh apps to the table.
-
Linux From Scratch 12.0 Now Available
If you're looking to roll your own Linux distribution, the latest version of Linux From Scratch is now available with plenty of updates.
-
Linux Kernel 6.5 Has Been Released
The newest Linux kernel, version 6.5, now includes initial support for two very exciting features.
-
UbuntuDDE 23.04 Now Available
A new version of the UbuntuDDE remix has finally arrived with all the updates from the Deepin desktop and everything that comes with the Ubuntu 23.04 base.
-
Star Labs Reveals a New Surface-Like Linux Tablet
If you've ever wanted a tablet that rivals the MS Surface, you're in luck as Star Labs has created such a device.
-
SUSE Going Private (Again)
The company behind SUSE Linux Enterprise, Rancher, and NeuVector recently announced that Marcel LUX III SARL (Marcel), its majority shareholder, intends to delist it from the Frankfurt Stock Exchange by way of a merger.