Kernel Watch

Jon Masters summarises the latest happenings in the Linux kernel community, for your reading pleasure.

Greg Kroah-Hartman has revealed details of the final release of Linux 4.19. In his announcement mail, Greg says that this latest kernel contains more changes than were present in each of the three previous releases.

The developer also alluded to Linus Torvalds having taken a break from maintaining the kernel in this cycle, in order to address his abusive language and lack of empathy towards fellow programmers and users over the years. Linus is coming back for the 4.20 release and Greg explains how now is a good time for everyone to reflect upon how we can bring out the best in one another going forward. The recently added Code of Conduct is one means through, which an attempt is being made to set expectations.

That Code of Conduct has seen some revisions in this cycle, mostly to add a few clarifications, including those needed to allow for typical developer workflows. The original document had stated that publishing an email address without permission was in violation of the code, but of course there are many traditionally accepted ways in which email addresses may innocently be included on patches, or in conversation.

Further tweaks are likely, but the underlying motivation to improve the overall experience of new and existing members of the community remains the same. As Greg says, not everyone who participates in or wants to join the community yet has “built-in knowledge of years of experience that thousands of us already do”, which makes it all the more important to treat one another well.

His mail is long, but worth reading (https://lkml.org/lkml/2018/10/22/184). Greg ended by encouraging everyone to take a day or two off for reflection, and to then start refreshed on the journey that will be Linux 4.20. And with that, he handed the baton back to Linus, saying, “You can have the joy of dealing with the merge window.” At time of writing, the “merge window” (period of time during which disruptive changes are allowed) is open.

What’s new in Linux 4.19?

Among the headline features added to 4.19 is support for the CAKE (Common Applications Kept Enhanced) network queuing discipline, a memory overhead reduction in OverlayFS (as used in containers), and experimental support for what will become Wi-Fi 6. It also contains numerous graphics driver enhancements, among which is support for a new Virtual Kernel ModeSetting Driver (KVMS) that can be used to leverage a GPU on headless machines.

The CAKE network queuing discipline is designed to improve the experience of users on relatively slow, often asymmetric network links (higher download speed than upload), such as home network users. A queuing discipline is an overly technical term for the policy used by the networking stack in determining what to do with individual network packets. CAKE aims to address the tendency for home networking equipment to overly buffer traffic, introducing latency and performance problems.

To address this, it adds a rate-based bandwidth shaper that knows about the behaviour of various technology common in such environments (such as in DOCSIS cable modems), among many other tweaks. This author plans to experiment with it as a replacement for custom hand-crafted Quality of Service rules that he uses.

OverlayFS is commonly used in Linux container deployments as a means of enabling the various layers of a container image to be mounted upon one another. A container base layer (typically the minimal guys of a Linux distribution) can be mounted read-only, while other layers within the container image can be used to replace specific components of the base layer, leveraging OverlayFS to make it possible for a container runtime to handle write attempts by storing those into a separate overlay. This works well today, but there are a number of inefficiencies in terms of memory footprint that 4.19 aims to solve. Those deploying containers at scale should notice this reduction, especially for certain file operations.

Changes to developer workflow

One of the changes that Greg had introduced into the 4.19 cycle while he was maintaining it were automated mails sent to developers acknowledging when their PRs (Pull Requests) were merged into upstream. This was very favourably received, and was in fact the topic of one of the first threads Linus instigated upon his return. Kernel.org infrastructure lead Konstantin Ryabitsev offered to assist in automating this

process, either through a web service called from a git pull request, or through other means of tracking list posts. We can likely expect something soon.

Ongoing development

John Hubbard posted an RFC (Request For Comment) patch series implementing get_user_

pages fixes for RDMA. RDMA (Remote Direct Memory Access) is a feature commonly used in high performance networking applications. It enables a user application or kernel code to write into memory that will be automatically copied to a remote system without the need to explicitly arrange this every time the memory is accessed. There are, however, a number of long-standing problems introduced when user application memory is being used for RDMA, such as when it contains filesystem data as an NFS over RDMA and similar. John’s patches aim to improve a situation that has seen obscure crashes.

Rick Edgecombe posted an RFC implemnting Rlimit (Resource Limits) for loadable kernel module space. This is necessitated by the presence of the BPF (Berkeley Packet Filter) JIT, which enables small programs to be provided by user code that will be run inside the kernel to filter incoming network traffic. It turns out that “If BPF JIT is on, there is no effective limit to prevent filling the entire module space with JITed e/BPF filters”. This not only wastes a lot of memory, but also causes a denial of service because kernel modules for regular drivers or other on-demand services can no longer be loaded. Jann Horn (the original Meltdown reporter at Google) noted a corner case, as usual.

Tim Chen has been working on patches to mitigate inter-application Spectre variant 2 attacks. Existing mitigations present in upstream kernels protect against malicious applications attacking the kernel across a privilege boundary, but they don’t protect against applications attacking one another.

This differs in some respects from vendor kernels. Tim is trying to upstream a generic solution, but one that also enables selective applications to optout of being protected, for performance reasons. This is handled similarly to Spectre variant 4 through the introduction of a new process control (prctl).

Applications can use this to request that they don’t need protection, the kernel can then default enable mitigation for any that do not opt out. The Linux Foundation Technical Advisory Board elections are taking place at Linux Plumbers Conference in Vancouver. Five of the ten members are up for re-election. Among other topics, the TAB is tasked with handling complaints of violations of the new Code of Conduct, as well as other policy matters.

“linux 4.19 contains more changes than were present in the three previous releases”