news
Kernel Articles in LWN
-
LWN ☛ Better CPU vulnerability mitigation configuration
Modern CPUs all have multiple hardware vulnerabilities that the kernel needs to mitigate; the 6.13 kernel has workarounds for 14 security-sensitive CPU bugs just on x86_64. Several of those have multiple variants, or multiple mitigations that apply on different microarchitectures. There are different kernel command-line options for each of these mitigations, which leads to a confusing situation for users trying to figure out how to configure their systems. David Kaplan recently posted a patch set that adds a single, unified command-line option for controlling mitigations and simplifies the logic for detecting, configuring, and applying them as well. If it is merged, the patch set could make it much easier for users to navigate the complicated web of CPU vulnerabilities and their mitigations.
-
LWN ☛ Warming up to frozen pages for networking
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.
The kernel uses reference counts to keep track of which pages of memory are in use. For example, a page in shared memory that is mapped into the address space of several processes will track a reference from each of those processes. As long as at least one of those processes exists and keeps the page mapped, that page will not be freed. The management of reference counts is not free, though; their manipulation requires expensive atomic operations, and the counts themselves take up memory. That has led to a desire to do without reference counting in places where it is not strictly necessary. The slab allocator, for example, tracks the objects it manages within each page and does not need a separate reference count for the page as a whole. In kernels prior to 6.14, though, slab pages are duly reference-counted anyway.
Frozen pages were introduced as a way to eliminate this overhead when possible; in a frozen page, the reference count is set to zero and stays there. Since the lifecycle of the page is tracked separately, there is no need to increment or decrement its count, so that overhead is avoided. Eventually, it will become possible to eliminate the reference count for frozen pages entirely (rather than just keeping it at zero), but there is work yet to be done to reach that point.
-
LWN ☛ Looking forward to mapcount madness 2025
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.
In theory, tracking mappings should be relatively straightforward: when a mapping to a page is added, increment that page's mapping count to match. The removal of a mapping should lead to an associated decrement of the mapping count. But huge pages and large folios complicate this scenario; they have their own mapping counts that are, essentially, the sum of the mapping counts for the pages they contain. It is often important to know whether a folio as a whole has mappings, so the separate count is useful, but it brings some complexities.