As has been recently discussed here, developers for the filesystem and memory-management subsystems have been grappling for years with the problems posed by the get_user_pages() mechanism. This function maps memory into the kernel’s address space for direct access by the kernel or peripheral devices, but that kind of access can create confusion in the filesystem layers, which may not be expecting that memory to be written to at any given time. A new patch set from Jérôme Glisse tries to chip away at a piece of the problem, but a complete solution is not yet in view.
The 5.1-rc5 announcement mentioned “changes all over” and highlighted a number of the areas that had been touched. One thing that was not mentioned there was the addition of four patches fixing a security-related issue in the core memory-management subsystem. The vulnerability is sufficiently difficult to exploit that almost nobody should feel the need to rush out a kernel update, but it is still interesting to look at as a demonstration of how things can go wrong.
Adrian Ratiu is posting a series of articles on the Collabora blog digging into the kernel’s eBPF subsystem. The first two parts are available now: an introduction and a look at the virtual machine. “eBPF is a RISC register machine with a total of 11 64-bit registers, a program counter and a 512 byte fixed-size stack. 9 registers are general purpouse read-write, one is a read-only stack pointer and the program counter is implicit, i.e. we can only jump to a certain offset from it. The VM registers are always 64-bit wide (even when running inside a 32-bit ARM processor kernel!) and support 32-bit subregister addressing if the most significant 32 bits are zeroed – this will be very useful in part 4 when cross-compiling and running eBPF programs on embedded devices.”
Running out of memory puts a Linux system into a difficult situation; in the worst cases, there is often no way out other than killing one or more processes to reclaim their memory. This killing may be done by the kernel itself or, on systems like Android, by a user-space out-of-memory (OOM) killer process. Killing a process is almost certain to make somebody unhappy; the kernel should at least try to use that process’s memory expeditiously so that, with luck, no other processes must die. That does not always happen, though, in current kernels. This patch set from Suren Baghdasaryan aims to improve the situation, but the solution that results in the end may take a different form.
Version 26.2 of the Emacs editor is out. The headline features include the ability to build modules outside of the source tree, Unicode 11 compliance, and the long-awaited ability to compress an entire directory full of files with a single keystroke.
Some things simply take time. When your editor restarted the search for a free accounting system, he had truly hoped to be done by now. But life gets busy, and accounting systems are remarkably prone to falling off the list of things one wants to deal with in any given day. On the other hand, accounting can return to that list quickly whenever LWN’s proprietary accounting software does something particularly obnoxious. This turns out to be one of those times, so your editor set out to determine whether beancount could do the job.
Here’s a research paper from Andrew Baumann, Jonathan Appavoo, Orran Krieger, and Timothy Roscoe at Microsoft Research arguing that the fork() system call is a fundamental design mistake. “As the designers and implementers of operating systems, we should acknowledge that fork’s continued existence as a first-class OS primitive holds back systems research, and deprecate it. As educators, we should teach fork as a historical artifact, and not the first process creation mechanism students encounter.” The discussion of better alternatives is limited, though.
Here’s a research paper from Andrew Baumann, Jonathan Appavoo, Orran Krieger, and Timothy Roscoe, published on the Microsoft Research site, arguing that the fork() system call is a fundamental design mistake. “As the designers and implementers of operating systems, we should acknowledge that fork’s continued existence as a first-class OS primitive holds back systems research, and deprecate it. As educators, we should teach fork as a historical artifact, and not the first process creation mechanism students encounter.” The discussion of better alternatives is limited, though.
“Sysctl” is the kernel’s mechanism for exposing tunable parameters to user space. Every sysctl knob is presented as a virtual file in a hierarchy under /proc/sys; current values can be queried by reading those files, and a suitably privileged user can change a value by writing to its associated file. What happens, though, when a system administrator would like to limit access to sysctl, even for privileged users? Currently there is no solution to this problem other than blocking access to /proc entirely. That may change, though, if this patch set from Andrey Ignatov makes its way into the mainline.
Memory fragmentation is a constant problem for memory-management subsystems. Over the years, considerable effort has been put into reducing fragmentation in the Linux kernel, but almost all of that work has been focused on memory management at the page level. The slab allocators, which (mostly) manage memory in chunks of less than the page size, have seen less attention, but fragmentation at this level can create problems throughout the system. The slab movable objects patch set posted by Tobin Harding is an attempt to improve this situation by making it possible for the kernel to actively defragment slab pages by moving objects around.
BleepingComputer reports that browser developers are removing the ability to disable “ping=” click tracking. “Google Chrome also enables this tracking feature by default, but in the current Chrome 73 version it includes a ‘Hyperlink auditing’ flag that can be used to disable it from the chrome://flags URL. In the Chrome 74 Beta and Chrome 75 Canary builds, though, this flag has been removed and there is no way to disable hyperlink auditing.” Firefox still allows this “feature” to be disabled (and disables it by default).
The fourth 5.1 kernel prepatch is out for testing. “Smaller than rc3, I’m happy to say. Nothing particularly big in here, just a number of small things all over.”
One of the new features in the 5.1 kernel is the pidfd_send_signal() system call. Combined with the (also new) ability to create a file descriptor referring to a process (a “pidfd”) by opening its directory in /proc, this system call allows for the sending of signals to processes in a race-free manner. An extension to this feature proposed for 5.2 has, however, sparked a discussion that has brought the whole concept into question. It may yet be that the pidfd feature will be put on hold before the final 5.1 release while the API around it is rethought.
Christian Schaller describes a long list of desktop improvements coming in the Fedora 30 release. “Screen sharing support for Chrome and Firefox under Wayland. The Wayland security model doesn’t allow any application to freely grab images or streams of the whole desktop like you could under X. This is of course a huge improvement in security, but it did cause some disruption for valid usecases like screen sharing with things like BlueJeans and Google Hangouts. We been working on resolving that with the help of PipeWire. We been at it for some time and things are now coming together. Chrome 73 ships with everything needed to make this work with Chrome.”
Chef, the purveyor of a popular configuration-management system, has announced a move away from the open-core business model and the open-sourcing of all of its software. “We aren’t making this change lightly. Over the years we have experimented with and learned from a variety of different open source, community and commercial models, in search of the right balance. We believe that this change, and the way we have made it, best aligns the objectives of our communities with our own business objectives. Now we can focus all of our investment and energy on building the best possible products in the best possible way for our community without having to choose between what is ‘proprietary’ and what is ‘in the commons.’”
One of the surest signs that the Linux Storage, Filesystem, and Memory-Management (LSFMM) Summit is approaching is the seasonal migration of memory-management developers toward the get_user_pages() problem. This core kernel primitive is necessary for high-performance I/O to user-space memory, but its interactions with filesystems have never been reliable — or even fully specified. There are currently a couple of patch sets in circulation that are attempting to improve the situation, though a full solution still seems distant.
The collective thoughts of the interwebz
By continuing to use the site, you agree to the use of cookies. more information
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.