All posts by corbet

[$] Page allocation for address-space isolation

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

Address-space isolation may well be, as Brendan Jackman said at the
beginning of his memory-management-track session at the 2025 Linux Storage,
Filesystem, Memory-Management, and BPF Summit, “some security
bullshit
“. But it also holds the potential to protect the kernel from
a wide range of vulnerabilities, both known and unknown, while reducing the
impact of existing mitigations. Implementing address-space isolation with
reasonable performance, though, is going to require some significant
changes. Jackman was there to get feedback from the memory-management
community on how those changes should be implemented.

[$] Better hugetlb page-table walking

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

The kernel must often step through the page tables of one or more processes
to carry out various operations. This “page-table walking” tends to be
performed by ad-hoc (duplicated) code all over the kernel. Oscar Salvador
used a memory-management-track session at the 2025 Linux Storage,
Filesystem, Memory-Management, and BPF Summit to talk about strategies to
unify the kernel’s page-table walking code just a little bit by making
hugetlb pages look more like ordinary pages.

[$] Approaches to reducing TLB pressure

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

The CPU’s translation lookaside buffer (TLB) caches the results of
virtual-address translations, significantly speeding memory accesses. TLB
misses are expensive, so a lot of thought goes into using the TLB as
efficiently as possible. Reducing pressure on the TLB was the topic of Rik
van Riel’s memory-management-track session at the 2025 Linux Storage,
Filesystem, Memory-Management, and BPF Summit. Some approaches were
considered, but the session was short on firm conclusions.

[$] Slab allocator: sheaves and any-context allocations

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

The kernel’s slab allocator is charged with providing small objects on
demand; its performance and reliability are crucial for the functioning of
the system as a whole. At the 2025 Linux Storage, Filesystem,
Memory-Management, and BPF Summit, two adjacent sessions in the
memory-management track dug into current work on the slab allocator. The
first focused on the new sheaves feature, while the second discussed a set
of allocation functions that are safe to call in any context.

Dave Täht RIP

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

[Dave Täht]

From the LibreQoS site comes the sad
news
that Dave Täht has passed away. Among many other things, he bears
a lot of credit for our networks functioning as well as they do. “We’re
incredibly grateful to have Dave as our friend, mentor, and as someone who
continuously inspired us – showing us that we could do better for each
other in the world, and leverage technology to make that happen. He will be
dearly missed
“.

Searching through LWN’s archives will turn up many references to his work
fixing WiFi, improving queue management, tackling bufferbloat, and more. Farewell,
Dave, we hope the music is good wherever you are.

(Thanks to Jon Masters for the heads-up).

[$] Memory persistence over kexec

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

The kernel’s kexec
mechanism
allows one kernel to directly boot a new one; it can be
thought of as a sort of kernel equivalent to the execve()
system call. Kexec has a number of uses, including booting a special kernel
to perform dumps after a crash. Normally, one does not expect user-space
processes to survive booting into a new kernel, but that has not stopped
developers from trying to implement that ability. Mike Rapoport ran a
memory-management-track session at the 2025 Linux Storage, Filesystem,
Memory-Management, and BPF Summit to discuss one piece of that problem:
enabling the contents of memory to persist across a kexec handover so that
the new kernel can pick up where the old one left off.

Security updates for Tuesday

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

Security updates have been issued by AlmaLinux (freetype, grub2, kernel, kernel-rt, and python-jinja2), Debian (freetype, linux-6.1, suricata, tzdata, and varnish), Fedora (mingw-libxslt and qgis), Mageia (elfutils, mercurial, and zvbi), Oracle (grafana, kernel, libxslt, nginx:1.22, and postgresql:12), Red Hat (opentelemetry-collector), SUSE (corosync, opera, and restic), and Ubuntu (aom, libtar, mariadb, ovn, php7.4, php8.1, php8.3, rabbitmq-server, and webkit2gtk).

[$] Improving the merging of anonymous VMAs

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

The virtual memory area (VMA), represented by struct
vm_area_struct
, is one of the core abstractions of the kernel’s
memory-management subsystem; a VMA represents a portion of a process’s
address space with the same characteristics. A memory-mapped file will be
represented by (at least) one VMA, as will the process’s stack or a region
of anonymous memory. Efficiently managing VMAs and the logic around them
is crucial for good performance overall. Lorenzo Stoakes focused on one
specific problem area: the merging of anonymous VMAs, during the
memory-management track at the 2025 Linux Storage, Filesystem,
Memory-Management, and BPF Summit.

[$] A herd of migration discussions

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

Migration is the act of moving data from one location in physical
memory to another. The kernel may migrate pages for many reasons,
including defragmentation, improving NUMA locality, moving data to or from
memory hosted on a peripheral device, or freeing a range of
memory for other uses. Given the importance of migration to the
memory-management subsystem, there is a lot of interest in improving its
performance and removing impediments to its success. Several sessions in
the memory-management track of the 2025 Linux Storage, Filesystem,
Memory-Management, and BPF Summit were dedicated to this topic.

[$] A process for handling Rust code in the core kernel

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

The 2024 Linux Storage, Filesystem, Memory-Management, and BPF Summit
included a tense session on the use of Rust
code in the kernel’s filesystem layer. The Rust topic returned in 2025 in
a session run by Andreas Hindborg, with a scope that also covered the
storage and memory-management layers. A lot of progress has been made, and
the discussion was less adversarial this year, but there are still process
issues that need to be worked out.

A new home for kernel.org

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

Akamai has sent out a
press release
saying that it is now hosting the kernel.org
repositories.

The Linux kernel is massive — approximately 28 million lines of
code. Since 2005, more than 13,500 developers from more than 1,300
different companies have contributed to the Linux
kernel. Additionally, there are many kernel versions, and
developers update the code constantly, distributing that code to
developers who are working on various distributions of
Linux. Akamai now delivers the infrastructure that these developers
and their users rely on, at no cost, supporting the Git
environments developers use to access kernel sources quickly,
regardless of where they’re based.

[$] LWN.net Weekly Edition for March 27, 2025

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

Inside this week’s LWN.net Weekly Edition:

  • Front: Open source in government; OSI election; Memory-management medley; Address-space isolation; CMA; 6.14 Development stats; State of the page.
  • Briefs: Asahi Linux progress; Reproducible Debian; rpi-image-gen; Neovim 0.11; OpenH264; Quotes; …
  • Announcements: Newsletters, conferences, security updates, patches, and more.

[$] The state of the page in 2025

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

The folio transition is one of the most
fundamental kernel changes ever made; it can be thought of as being similar
to replacing the foundation of a building while it remains open for
business. So it is not surprising that, for some years, the annual Linux
Storage, Filesystem, Memory-Management, and BPF Summit has included a
session on the state of this transition. The 2025 Summit was no exception,
with Matthew Wilcox updating the group on what has been accomplished, what
remains to be done, and where some of the significant problems are.

[$] Development statistics for 6.14

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

By the time that Linus Torvalds released
the 6.14 kernel, 11,003 non-merge changesets had been pulled into the
mainline, making this one of the smallest releases we have seen in some
time. Indeed, one must go back to the 4.0
release
, which happened almost exactly ten years ago, to find a release
with fewer changesets than 6.14. Even so, “small” is relative, and 6.14
contains a lot of significant changes.

Security updates for Tuesday

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

Security updates have been issued by Debian (ruby-rack), Fedora (chromium, golang-github-openprinting-ipp-usb, OpenIPMI, and python-jinja2), Mageia (kernel, kernel-linus, and wpa_supplicant, hostapd), Red Hat (fence-agents, kernel, kernel-rt, libxml2, libxslt, and pcs), SUSE (cadvisor, docker, freetype2, nodejs-electron, php8, rsync, u-boot, warewulf4, webkit2gtk3, and zvbi), and Ubuntu (elfutils, python3.5, python3.8, ruby-rack, smartdns, and zvbi).