When Brendan Jackman proposed a session for the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, his topic was "a pagetable library for the kernel". During the actual memory-management-track session, though, he stated that the idea had "fizzled" and he was going to cover related topics instead. What resulted was a session on ways to efficiently manage pages that are not present in the kernel's direct map.

Linux can share memory between processes, but each process (almost always) has its own set of page tables. In situations where vast numbers of processes are sharing a memory region, the combined size of the page tables can exceed that of the shared memory itself. There has, thus, long been an interest in enabling unrelated processes to share page tables referring to shared memory. Anthony Yznaga is the latest developer to try to push this idea (known as "mshare") forward; he described the status of that work in a memory-management-track discussion at the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit (LSFMM+BPF).

The KDE project has announced that it has been awarded over €1 million from the Sovereign Tech Fund to improve its desktop-environment software. "The investment will be used to strengthen the structural reliability and security of KDE's core infrastructure, including Plasma, KDE Linux, and the frameworks underlying its communication services."

The kernel's dma-buf subsystem provides a way for drivers to share memory buffers, usually in order to support efficient device-to-device I/O. At the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, Pavel Begunkov, assisted by Kanchan Joshi, led a joint session of the storage and memory-management tracks to explore ways to make the use of dma-bufs more efficient yet, and to make them available for read and write operations initiated by user space.

As a general rule, when developers talk about huge pages, they are referring to PMD-level pages that are 1MB or 2MB in size, depending on the CPU architecture. Most CPUs can support other huge-page sizes, though. On x86 systems, PUD-level huge pages hold 1GB of data. Providing such large pages transparently to processes has generally not been considered as either feasible or desirable, but Usama Arif is trying to change that assessment. At the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, he led a session in the memory-management track on how to make transparent huge pages (THPs) truly huge.

Some CPU architectures are able to run with a number of different base-page sizes; using a larger size can often result in better performance at the cost of increased memory use. Other architectures are more limited. At the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, two sessions in the memory-management track explored options for letting processes run with 64KB page sizes when the underlying kernel does not. The first was focused on letting each process have its own page size, while the second concerned bringing 64KB pages to x86 systems.

Paul Gevers has slipped an interesting bit of news into a "bits from the release team" message:

Aided by the efforts of the Reproducible Builds project, we've decided it's time to say that Debian must ship reproducible packages. Since yesterday, we have enabled our migration software to block migration of new packages that can't be reproduced or existing packages (in testing) that regress in reproducibility.

As Gioele Barabucci pointed out, "reproducible" in this sense is limited to building within an instance of Debian's build environment, which is a tighter requirement than is normally used. It is still a big step forward for reproducible builds.

Linus has released 7.1-rc3 for testing. "I think this answers the 'is 7.1 continuing the larger size pattern that we saw with 7.0?' question, and the answer is yes: that wasn't a fluke brought on by a .0 release - it simply seems to be the new normal."

It seems that we are in for an extended period of the disclosure of vulnerabilities before fixes become available. One possible way of coping with this flood might be the killswitch proposal from Sasha Levin. In short, killswitch can immediately disable access to specific functionality in a running kernel, essentially blasting a vulnerable path (and its associated functionality) out of existence until a fix can be installed. "For most users, the cost of 'this socket family stops working for the day' is much smaller than the cost of running a known vulnerable kernel until the fix land."

The kernel's DAMON subsystem provides user-space monitoring and management of system memory. DAMON is developing rapidly, so an update on its progress has become a regular feature of the annual Linux Storage, Filesystem, Memory Management, and BPF Summit. This tradition continued at the 2026 gathering with an update from DAMON creator SeongJae Park covering a long list of new capabilities — tiering, data attributes monitoring, transparent huge pages, and more — being added to this subsystem.

On April 21, Andrew Morton let it be known that he intends to begin stepping away from the maintainership of kernel's memory-management subsystem — a responsibility he has carried since before memory management was even seen as its own subsystem. At the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, one of the first sessions in the memory-management track was devoted to how the maintainership would be managed going forward. There are a lot of questions still to be answered.

The 7.0.4, 6.18.27, and 6.12.86 stable kernels have been released; each contains another set of important fixes.

Inside this week's LWN.net Weekly Edition:

• Front: LLMs and security; restartable sequences and TCMalloc; Fedora and GNOME bug reports; Prolly trees; Arm on s390.
• Briefs: NHS open source; Alpine outage; GCC 16.1; Incus 7.0 LTS; NetHack 5.0.0; PHP license; Quotes; ...
• Announcements: Newsletters, conferences, security updates, patches, and more.

The PHP project has long shipped under its own license — except for the parts under the Zend Engine License. The PHP project has now announced that the PHP license has been retired, and the PHP code has been relicensed under the three-clause BSD license. See this blog entry for more details.

Getting here required more than writing an RFC. The PHP License gives the PHP Group the authority to change it, which meant tracking down each of the original PHP Group members and getting their written consent. Each approved the proposal. Perforce Software, the successor to Zend Technologies, needed to sign off on the Zend Engine side, as well. They provided a formal letter confirming their full authority and support for the change. I hired an attorney to review the proposal and provide advice on any legal questions that might surface during the discussion period. Speaking of which, I allowed for a six-month community discussion period preceding the vote, which passed unanimously.

LWN covered the license-change process back in March.

The second 7.1 kernel prepatch is out for testing. "It's not small, and while it's a bit early to say for sure, I do suspect we're seeing the same continued pattern of more patches than usual - probably due to AI tooling - that we saw in 7.0."

Hyrum's Law states that any observable behavior of a system will eventually be depended upon by somebody. The kernel community is currently contending with a clear demonstration of that principle. The recent work to address some restartable-sequences performance problems in the 6.19 release maintained the documented API in all respects, but that was not enough; Google's TCMalloc library, as it turns out, violates the documented API, prevents other code from using restartable features, and breaks with 6.19. But the kernel's no-regressions rule is forcing developers to find a way to accommodate TCMalloc's behavior.

Inside this week's LWN.net Weekly Edition:

• Front: Famfs; Python packaging council; Zig concurrency; pages and folios; Strawberry music manager; 7.1 merge window.
• Briefs: GnuPG 2.5.19; Copy Fail; Plasma security; Fedora 44; Ubuntu 26.04; Niri 26.04; pip 26.1; RIP Seth Nickell; RIP Tomáš Kalibera; Quotes; ...
• Announcements: Newsletters, conferences, security updates, patches, and more.

By the time Linus Torvalds released 7.1-rc1 and closed the 7.1 merge window, 12,996 non-merge changesets had been pulled into the mainline repository; just over 9,000 of those arrived after the first-half summary was written. These changes were more driver-oriented than those seen earlier, but still also included many new features across the kernel as a whole.

Linus has released 7.1-rc1 and closed the merge window for this release.

Things look fairly normal, although we do have a few different projects to cull some old hardware support to help minimize maintenance burden: phasing out i486 support (configs deleted, code deletions to follow) and independently starting to remove some really old networking hardware support, and removing some SoC support that never went anywhere.

But we're more than making up for any stale code removal with all the new features and code added, so the diffstat still shows many more lines added than removed.

The kernel coverage here at LWN often touches on memory-management topics and, as a result, tends to talk a lot about both pages and folios. As the folio transition in the kernel has moved forward, it has often become difficult to decide which term to use in writing that is meant to be both approachable and technically correct. As this work continues, it will be increasingly common to use "folio" rather than page. This article is intended to be a convenient reference for readers wanting to differentiate the two terms or understand the state of this transition.