All posts by corbet

[$] 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).

The 6.14 kernel is out

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

Linus has released the 6.14 kernel, a bit
later than expected:

So it’s early Monday morning (well – early for me, I’m not really a
morning person), and I’d love to have some good excuse for why I
didn’t do the 6.14 release yesterday on my regular Sunday afternoon
release schedule.

I’d like to say that some important last-minute thing came up and
delayed things.

But no. It’s just pure incompetence.

See the LWN merge-window summaries (part 1, part 2) and the KernelNewbies 6.14 page
for details on what’s new in this release.

[$] The guaranteed contiguous memory allocator

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

As a system runs and its memory becomes fragmented, allocating large,
physically contiguous regions of memory becomes increasingly difficult.
Much effort over the years has gone into avoiding the need to make such
allocations whenever possible, but there are times when they simply cannot
be avoided. The kernel’s contiguous memory
allocator
(CMA) subsystem attempts to make such allocations possible,
but it has never been a perfect solution. Suren Baghdasaryan is is trying
to improve that situation with the guaranteed
contiguous memory allocator patch set
, which includes work from Minchan
Kim as well.

An Asahi Linux 6.14 progress report

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

The Asahi Linux project, working to support Linux on Apple hardware, has
published a
progress report
to coincide with the 6.14 kernel release.

Now that Rust for Linux abstractions are starting to be merged at a
healthy pace, we are faced with an emerging challenge. It is rare
for any kernel patch to survive the mailing list without at least a
couple of non-trivial changes, and Rust abstractions are no
exception. Every time an abstraction used by our driver is merged,
we must drop our downstream version and rebase the driver atop the
version accepted upstream. This is grueling, menial, and
unpleasant work, and Janne has our deepest gratitude for
volunteering his time to get through it.

[$] MM medley: huge page allocation, page promotion, KSM, and BPF

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

As the 2025 Linux
Storage, Filesystem, Memory-Management, and BPF Summit
(LSFMM+BPF)
approaches, the density of memory-management patches on the mailing lists
has increased. Included among those are patches aimed at improving the
reliability and performance of huge-page allocation, implementing page
promotion on tiered-memory systems, adding a different approach to
deduplicating memory, and replacing the BPF memory allocator. Read on for
an overview of each.

Supply Chain Attacks on Linux distributions (Fenrisk)

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

A security company called Fenrisk has posted an overview of a pair
of claimed successful supply-chain attacks on the Fedora and openSUSE
distributions.

We successfully identified vulnerabilities in the Pagure, the Git
forge used by Fedora to store their package definitions. We also
compromised Open Build Service, the all-in-one toolchain used and
developed by the openSUSE project for compilation and packaging.

Their exploitation by malicious actors would have led to the
compromise of all the packages of the distributions Fedora and
openSUSE, as well as their downstream distributions, impacting
millions of Linux servers and desktops.

[$] Looking forward to mapcount madness 2025

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

One of the many important tasks that the kernel’s memory-management
subsystem must handle is keeping track of how pages of memory are mapped
into the address spaces of the processes running on the system. As long as
mappings to a given page exist, that page must be kept in place. As it
turns out, tracking these mappings is harder than it seems it should be,
and the move to folios within the memory-management subsystem is adding
some complexities of its own. As a follow-up to the “mapcount madness” session that he ran at
the 2024 Linux Storage, Filesystem,
Memory-Management, and BPF summit
, David Hildenbrand has posted a patch series
intended to improve the handling of mapping counts for folios — but exact
accounting remains elusive in some situations.

[$] Warming up to frozen pages for networking

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

When the 6.14 kernel is released later this month, it will include the
usual set of internal changes that users should never notice, with the
possible exception of changes that bring performance improvements. One of
those changes is frozen pages, a
memory-management optimization that should fly mostly under the radar.
When Hannes Reinecke reported a
crash
in 6.14, though, frozen pages suddenly came into view. There is a
workaround for this problem, but it seems there is a fair
amount of work to be done that nobody had counted on to solve the problem
properly.