All posts by corbet

[$] Sharing page tables with mshare()

Post Syndicated from corbet original https://lwn.net/Articles/895217/

The Linux kernel allows processes to share pages in memory, but the page
tables used to control that sharing are not, themselves, shared; as a
result, processes sharing memory maintain duplicate copies of the
page-table data. Normally this duplication imposes little overhead, but
there are situations where it can hurt. At the 2022 Linux Storage,
Filesystem, Memory-management and BPF Summit (LSFMM), Khaled Aziz
(remotely) and Matthew Wilcox led a session to discuss a proposed mechanism
to allow those page tables to be shared between cooperating processes.

Security updates for Tuesday

Post Syndicated from corbet original https://lwn.net/Articles/895521/

Security updates have been issued by Debian (cifs-utils, ffmpeg, libxml2, and vim), Fedora (rsyslog), Mageia (chromium-browser-stable), SUSE (chromium, containerd, docker, e2fsprogs, gzip, jackson-databind, jackson-dataformats-binary, jackson-annotations, jackson-bom, jackson-core, kernel, nodejs8, openldap2, pidgin, podofo, slurm, and tiff), and Ubuntu (clamav, containerd, libxml2, and openldap).

[$] Proactive reclaim for tiered memory and more

Post Syndicated from corbet original https://lwn.net/Articles/894849/

Memory reclaim in Linux is largely a reactive practice; the kernel tries to
find memory it can repurpose in response to the amount of free memory
falling too low. Developers have often wondered if a proactive reclaim
mechanism might lead to better performance, for some workloads at least,
and optimal use of tiered-memory systems will likely require more active
reclamation of memory as well. At the 2022 Linux Storage,
Filesystem, Memory-management and BPF Summit (LSFMM), Davidlohr Bueso
led a brief session on the topic.

[$] CXL 1: Management and tiering

Post Syndicated from corbet original https://lwn.net/Articles/894598/

Compute Express
Link (CXL) is an upcoming memory technology that is clearly on the
minds of Linux memory-management developers; there were five sessions
dedicated to the topic at the 2022 Linux Storage,
Filesystem, Memory-management and BPF Summit (LSFMM). The first three
sessions, on May 3, covered various aspects of memory management in the
presence of CXL. It seems that
CXL may bring some welcome capabilities, especially for cloud-service
providers, but that will come at the cost of some headaches on the
kernel-development side.

[$] Merging the multi-generational LRU

Post Syndicated from corbet original https://lwn.net/Articles/894859/

Many types of kernel changes can be hammered into shape on the mailing
lists. There are certain types of patches, however, that have a hard time getting to
the finish line that way; they are sufficiently large and invasive that
they need an actual gathering of the developers involved. The multi-generational LRU work (MGLRU) falls into this
category, which is why it was the subject of a full-hour session at the 2022 Linux Storage,
Filesystem, Memory-management and BPF Summit (LSFMM). The discussion
held there may well have opened the doors for this code to be merged in the
near future.

[$] Solutions for direct-map fragmentation

Post Syndicated from corbet original https://lwn.net/Articles/894557/

The kernel’s “direct map” makes the entirety of a system’s physical memory
available in the kernel’s virtual address space. Normally, huge pages are used for
this mapping, making it relatively efficient to access. Increasingly,
though, there is a need to carve some pages out of the direct map; this
splits up those huge pages and makes the system as a whole less efficient.
During a memory-management session at the
2022
Linux Storage, Filesystem, Memory-management and BPF Summit (LSFMM),
Mike Rapoport led a session on direct-map fragmentation and how it might be
avoided.

NVIDIA Transitioning To Official, Open-Source Linux GPU Kernel Driver (Phoronix)

Post Syndicated from corbet original https://lwn.net/Articles/894861/

Phoronix reports
that the days of proprietary NVIDIA graphics drivers are coming to a close.

NVIDIA’s open kernel modules is already considered “production
ready, opt-in” for data center GPUs. For GeForce and workstation
GPUs, the open kernel module code is considered “alpha quality” but
will be ramped up moving forward with future releases. NVIDIA has
already deprecated the monolithic kernel module approach for their
data center GPU support to focus on this open kernel driver
solution (and their existing proprietary kernel module using the
GSP). Only Turing and newer GPUs will be supported by this
open-source kernel driver. Pre-Turing GPUs are left to using the
existing proprietary kernel drivers or the Nouveau DRM driver for
that matter.

The user-space code remains proprietary, though, which could inhibit the
eventual merging of this code into the mainline kernel.

Update: here is NVIDIA’s
press release on the new drivers.

[$] Better tools for out-of-memory debugging

Post Syndicated from corbet original https://lwn.net/Articles/894546/

Out-of-memory (OOM) situations are dreaded by users, system administrators,
and kernel developers alike. Usually, all that is known is that a lot of
memory is being used somewhere and the system has run out, but the kernel provides little help to
anybody trying to figure out where the memory has gone. In a memory-management
session at the 2022
Linux Storage, Filesystem, Memory-management and BPF Summit (LSFMM),
Kent Overstreet asked what could be done to improve OOM reports and reduce
the pain for all involved.

[$] Seeking an API for protection keys supervisor

Post Syndicated from corbet original https://lwn.net/Articles/894531/

Memory protection keys are a CPU feature that allows additional access
restrictions to be imposed on regions of memory and changed in a fast and
efficient way. Support for protection keys in user space has been in the
kernel for some time, but kernel-side protection (often called “protection
keys supervisor” or PKS) remains unsupported — on x86, at least. At the
2022 Linux
Storage, Filesystem, Memory-management and BPF Summit (LSFMM), Ira
Weiny provided an update on the state of PKS and led a discussion on what
the proper in-kernel API for PKS should be.

The malicious “rustdecimal” crate

Post Syndicated from corbet original https://lwn.net/Articles/894808/

The Rust Blog warns
developers of a malicious crate named rustdecimal, which was
evidently targeted at GitLab users who mistype rust_decimal.

The crate contained identical source code and functionality as the
legit rust_decimal crate, except for the Decimal::new function.

When the function was called, it checked whether the GITLAB_CI
environment variable was set, and if so it downloaded a binary
payload into /tmp/git-updater.bin and executed it. The binary
payload supported both Linux and macOS, but not Windows.

Security updates for Wednesday

Post Syndicated from corbet original https://lwn.net/Articles/894802/

Security updates have been issued by Debian (mutt), Fedora (blender, freerdp, kernel, kernel-headers, kernel-tools, mingw-freetype, and vim), Oracle (kernel and kernel-container), Red Hat (aspell, bind, bluez, c-ares, cairo and pixman, cockpit, compat-exiv2-026, container-tools:3.0, container-tools:rhel8, cpio, dovecot, exiv2, fapolicyd, fetchmail, flatpak, gfbgraph, gnome-shell, go-toolset:rhel8, grafana, grub2, httpd:2.4, keepalived, kernel, kernel-rt, libpq, libreoffice, libsndfile, libssh, libtiff, lynx, maven:3.5, maven:3.6, mod_auth_mellon, mod_auth_openidc:2.3, openssh, php:7.4, pki-core:10.6, postgresql:10, python-lxml, python27:2.7, python3, python38:3.8 python38-devel:3.8, python39:3.9 python39-devel:3.9, qt5-qtbase, qt5-qtsvg, rust-toolset:rhel8, samba, squid:4, udisks2, virt:rhel virt-devel:rhel, webkit2gtk3, xorg-x11-server xorg-x11-server-Xwayland, and zsh), SUSE (gzip and php-composer), and Ubuntu (busybox, cairo, cron, dnsmasq, libsndfile, and nss).

[$] Page pinning and filesystems

Post Syndicated from corbet original https://lwn.net/Articles/894390/

It would have been surprising indeed if the 2022 Linux Storage,
Filesystem, Memory-management and BPF Summit (LSFMM) did not include a
session working toward solutions to the longstanding problems with
get_user_pages(), an internal function that locks user-space pages
in memory for access by the kernel. The issue has, after all, come up numerous times
over the years. This year’s event duly contained a session in the joint
filesystem and memory-management track, led by John Hubbard, with a focus
on page pinning and how it interacts with filesystems.

[$] The state of memory-management development

Post Syndicated from corbet original https://lwn.net/Articles/894378/

The 2022 Linux
Storage, Filesystem, Memory-management and BPF Summit (LSFMM) was the
first chance for Linux memory-management developers to gather in three
years. In a session at the end of the first day led by maintainer Andrew
Morton, those developers discussed the memory-management development
process. While the overall governance will remain the same, there are
nonetheless some significant changes in store for this subsystem.

[$] Improving memory-management documentation

Post Syndicated from corbet original https://lwn.net/Articles/894374/

Like much of the kernel, the memory-management subsystem is under-documented,
and much of the documentation that does exist is less than fully current.
At the 2022 Linux
Storage, Filesystem, Memory-management and BPF Summit (LSFMM), Mike
Rapoport ran a session on memory-management documentation and what can be
done to improve it. The result was a reinvigorated interest in
documentation, but only time will tell what actual improvements will come
from that interest.