This patch from Johannes Weiner seemed like a straightforward way to improve memory-reclaim performance; without it, the virtual filesystem layer throws away memory that the memory-management subsystem thinks is still worth keeping. But that patch quickly ran afoul of a feature (or "misfeature" depending on who one asks) from the distant past, one which goes by the name of "high memory". Now, more than 20 years after its addition, high memory may be brought down low, as developers consider whether it should be deprecated and eventually removed from the kernel altogether.

Security updates have been issued by CentOS (kernel, ksh, python-pillow, and thunderbird), Debian (opensmtpd, proftpd-dfsg, and rake), Fedora (NetworkManager-ssh), openSUSE (chromium), and SUSE (libexif, mariadb, ovmf, python3, and squid).

The LWN.net Weekly Edition for February 27, 2020 is available.

The "kernel runtime security instrumentation" (KRSI) patch set has been making the rounds over the past few months; the idea is to use the Linux security module (LSM) hooks as a way to detect, and potentially deflect, active attacks against a running system. It does so by allowing BPF programs to be attached to the LSM hooks. That has caused some concern in the past about exposing the security hooks as external kernel APIs, which makes them potentially subject to the "don't break user space" edict. But there has been no real objection to the goals of KRSI. The fourth version of the patch set was posted by KP Singh on February 20; the concerns raised this time are about its impact on the LSM infrastructure.

Security updates have been issued by Debian (python-pysaml2), Mageia (clamav, graphicsmagick, opencontainers-runc, squid, and xmlsec1), Oracle (kernel, ksh, python-pillow, systemd, and thunderbird), Red Hat (rh-nodejs12-nodejs), Scientific Linux (ksh, python-pillow, and thunderbird), and SUSE (nodejs6, openssl, ppp, and squid).

BPF has exploded within the Linux world over the last few years, growing from its networking roots into the go-to tool for running custom in-kernel programs. Its role seems to expand with every kernel release into diverse areas such as security and device control. But none of that is the focus of a relatively new book from Brendan Gregg, BPF Performance Tools; it looks, instead, at how BPF provides visibility into the guts of the kernel. Finding performance bottlenecks of various sorts on (generally large) production systems is an area where BPF and the tool set that has grown up around it can excel; Gregg's book describes that landscape in great depth.

Version 19 of the Arch-based Manjaro distribution is out. "The Xfce edition remains our flagship offering and has received the attention it deserves. Only a few can claim to offer such a polished, integrated and leading-edge Xfce experience. With this release we ship Xfce 4.14 and have mostly focused on polishing the user experience with the desktop and window manager. Also we have switched to a new theme called Matcha. A new feature Display-Profiles allows you to store one or more profiles for your preferred display configuration. We also have implemented auto-application of profiles when new displays are connected."

The Free Software Foundation has announced that it is planning to launch a public code hosting and collaboration platform later this year. "We plan on contributing improvements upstream for the new forge software we choose, to boost its score on [GNU ethical repository] criteria. Our tech team is small for the size of the network we maintain, and we don't have any full-time developers who work for the FSF, so we are limited in the amount of time we can spend on the software we choose. We'll communicate with the upstream developers to request improvements and help clarify any questions related to the ethical repository criteria."

Security updates have been issued by Debian (curl and otrs2), Fedora (NetworkManager-ssh and python-psutil), Mageia (ipmitool, libgd, libxml2_2, nextcloud, radare2, and upx), openSUSE (inn and sudo), Oracle (kernel, ksh, python-pillow, and thunderbird), Red Hat (curl, kernel, nodejs:10, nodejs:12, procps-ng, rh-nodejs10-nodejs, ruby, and systemd), SUSE (dpdk, firefox, java-1_7_1-ibm, java-1_8_0-ibm, libexif, libvpx, nodejs10, nodejs8, openssl1, pdsh, slurm_18_08, python-azure-agent, python3, and webkit2gtk3), and Ubuntu (libapache2-mod-auth-mellon, libpam-radius-auth, and rsync).

Filesystems, by design, hide a lot of complexity from users. At times, though, those users need to be able to look inside the black box and extract information about what is going on within a filesystem. Answering this need is David Howells, the creator of a number of filesystem-oriented system calls; in this patch set he tries to add three more, one of which we have seen before and two of which are new.

The 5.6-rc3 kernel prepatch is out for testing. Linus says: "Fairly normal rc3 as far as I can tell. We've seen bigger, but we've seen smaller ones too. Maybe this is slightly on the low side of average at this time, which would make sense since this was a smaller merge window. Anyway, too much noise in the signal to be sure either way."

Stable kernels 5.5.6, 5.4.22, and 4.19.106 have been released. They all have a large set of important fixes.

Security updates have been issued by Debian (libpam-radius-auth, pillow, ppp, proftpd-dfsg, and python-pysaml2), Fedora (firefox, glib2, hiredis, http-parser, libuv, mingw-openjpeg2, nghttp2, nodejs, openjpeg2, python-pillow, skopeo, and webkit2gtk3), Mageia (patch, postgresql, and systemd), Red Hat (ksh, nodejs:10, openjpeg2, python-pillow, systemd, and thunderbird), and SUSE (java-1_7_1-ibm, libsolv, libzypp, zypper, pdsh, slurm_18_08, and php53).

The perf_event_open() system call is a complicated beast, requiring a fair amount of study to master. This call also has some interesting security implications: it can be used to obtain a lot of information about the running system, and the complexity of the underlying implementation has made it more than usually prone to unpleasant bugs. In current kernels, the security controls around perf_event_open() are simple, though: if you have the CAP_SYS_ADMIN capability, perf_event_open() is available to you (though the system administrator can make it available without any privilege at all). Some current work to create a new capability for the perf events subsystem would seem to make sense, raising the question of why adding new capabilities isn't done more often.

Security updates have been issued by CentOS (openjpeg2), Debian (cloud-init, jackson-databind, and python-reportlab), Red Hat (ksh, python-pillow, systemd, and thunderbird), Slackware (proftpd), SUSE (java-1_7_0-ibm, nodejs10, and nodejs12), and Ubuntu (ppp and squid, squid3).

To a great extent, memory management is based on making predictions: which pages of memory will a given process need in the near future? Unfortunately, it turns out that predictions are hard, especially when they are about future events. In the absence of useful information sent back from the future, memory-management subsystems are forced to rely on observations of recent behavior and an assumption that said behavior is likely to continue. The kernel's memory-management decisions are opaque to user space, though, and often result in less-than-optimal performance. A pair of patch sets from SeongJae Park tries to make memory-usage patterns visible to user space, and to let user space change memory-management decisions in response.

Security updates have been issued by Debian (netty and netty-3.9), Fedora (ceph, dovecot, poppler, and webkit2gtk3), openSUSE (inn and rmt-server), Oracle (openjpeg2), Red Hat (rabbitmq-server), Scientific Linux (openjpeg2), SUSE (dnsmasq, rsyslog, and slurm), and Ubuntu (php7.0).

The LWN.net Weekly Edition for February 20, 2020 is available.

Stable kernels 5.5.5, 5.4.21, and 4.19.105 have been released, with the usual set of important fixes.

At this point, most of the kernel work to avoid the year-2038 apocalypse has been completed. Said apocalypse could occur when time counted in seconds since 1970 overflows a 32-bit signed value (i.e. time_t). Work in the GNU C Library (glibc) and other C libraries is well underway as well. But the "fun" is just beginning for distributions, especially those that support 32-bit architectures, as a recent Debian discussion reveals. One of the questions is: how much effort should be made to support 32-bit architectures as they fade from use and 2038 draws nearer?