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
-
Juno Computers Launches Another Linux Laptop
If you're looking for a powerhouse laptop that runs Ubuntu, the Juno Computers Neptune 17 v6 should be on your radar.
-
ZorinOS 17.1 Released, Includes Improved Windows App Support
If you need or desire to run Windows applications on Linux, there's one distribution intent on making that easier for you and its new release further improves that feature.
-
Linux Market Share Surpasses 4% for the First Time
Look out Windows and macOS, Linux is on the rise and has even topped ChromeOS to become the fourth most widely used OS around the globe.
-
KDE’s Plasma 6 Officially Available
KDE’s Plasma 6.0 "Megarelease" has happened, and it's brimming with new features, polish, and performance.
-
Latest Version of Tails Unleashed
Tails 6.0 is based on Debian 12 and includes GNOME 43.
-
KDE Announces New Slimbook V with Plenty of Power and KDE’s Plasma 6
If you're a fan of KDE Plasma, you'll be thrilled to hear they've announced a new Slimbook with an AMD CPU and the latest version of KDE Plasma desktop.
-
Monthly Sponsorship Includes Early Access to elementary OS 8
If you want to get a glimpse of what's in the pipeline for elementary OS 8, just set up a monthly sponsorship to help fund its continued existence.
-
DebConf24 to be Held in South Korea
Busan will be the location of the latest DebConf running July 28 through August 4
-
Fedora Unleashes Atomic Desktops
Fedora has combined its solid distribution with rpm-ostree system to make it possible to deliver a new family of Fedora spins, called Fedora Atomic Desktops.
-
Bootloader Vulnerability Affects Nearly All Linux Distributions
The developers of shim have released a version to fix numerous security flaws, including one that could enable remote control execution of malicious code under certain circumstances.