Linus Torvalds released 7.2-rc1 and closed the 7.2 merge window on June 28; by that time, 13,412 non-merge commits had found their way into the mainline. That makes this the busiest merge window since the 6.7 development cycle in 2024 (15,418 commits, including 2,800 for the entire bcachefs development history). Just under half of those commits arrived after LWN's summary of the first half of the merge window was written. As usual, the commits in the latter part of the merge window were more heavily focused on fixes, but there were still a lot of new features and significant changes merged as well.

The 7.2-rc1 kernel prepatch is out for testing. Linus said: "So two weeks have passed, and the merge window is closed. Things look reasonably normal for this release (knock wood)."

The 7.1.2, 7.0.14, and 6.18.37 stable kernel updates have been released; each contains a relatively small number of important fixes. Note that 7.0.14 is the end of the 7.0.x series.

The Power Management and Scheduling in the Linux Kernel Summit, which still goes by the historical acronym OSPM, was held in Cambridge, UK, in mid-April. As has become traditional, the presenters at that event have since written summaries of their sessions, and this work has kindly been made available to LWN for publication. The third day's sessions covered a wide range of topics, including GPU affinity, profile-guided scheduling, paravirtualization scheduling, quality of service, and more.

Lennart Poettering has posted a list of Mastodon posts about the changes in the systemd v261 release. The Mastodon format makes the reading harder, but there is a lot of useful information there.

The Git v2.55.0-rc2 testing release appeared on June 23, suggesting that the final Git 2.55 release can be expected in the near future. While this Git update lacks radical new features, it does include a number of improvements that regular Git users will appreciate, including commands to easily edit the commit history, more formatting options, fsmonitor support for Linux, and more.

The Linux Foundation, in a letter co-signed by a large range of organizations and companies, has announced the launch of "Akrites", a project to fast-track vulnerability fixes into projects.

As Akrites works upstream to fix projects at the source, we commit to support downstream efforts to secure critical infrastructure before it can be exploited. When patches are released to the public, adversaries are able to utilize AI to rapidly reverse engineer the underlying vulnerabilities, develop exploits, and launch attacks. The success of our efforts therefore will be measured in patch deployment, not publication. We will partner with critical infrastructure owners and operators, civil society efforts, and governments as they increase coordination to achieve these goals.

Confidentiality is non-negotiable: An undisclosed flaw in a widely deployed package is, in effect, a weapon, and the program is built first to prevent leaks. Fixes flow back into each project's own home, working with the maintainers. The engineering resources and other capabilities provided by Akrites participants contribute to this effort. Additionally, when a critical package has no one maintaining it, Akrites will stand as the maintainer of last resort so a fix can still reach everyone in a timely fashion. We will also align with government efforts so that public and private defenders move together, rather than in a disjointed fashion.

There is a lot of work going into eliminating exploitable bugs from the kernel and preventing the addition of new ones. Even if this work is maximally successful, though, there is no chance that the kernel will be free of these bugs anytime soon. Thus, there is also ongoing interest in hardening the kernel to make the existing bugs more difficult to exploit. The upcoming 7.2 kernel release will include a change to how dynamically allocated structures are placed in memory to make them harder to overwrite, while a project to randomize structure layout at boot time has a rather longer timeline.

The Power Management and Scheduling in the Linux Kernel Summit, which still goes by the historical acronym OSPM, was held in Cambridge, UK, in mid-April. As has become traditional, the presenters at that event have since written summaries of their sessions, and this work has kindly been made available to LWN for publication. The second day's sessions covered a wide range of topics, including device frequency scaling, using time-slice duration for CPU selection, scheduling domains on multi-cluster Arm systems, the LAVD scheduler, and more.

The Power Management and Scheduling in the Linux Kernel Summit, which still goes by the historical acronym OSPM, was held in Cambridge, UK, in mid-April. As has become traditional, the presenters at that event have since written summaries of their sessions, and this work has kindly been made available to LWN for publication. The first day's sessions covered a wide range of topics, including idle-state selection, user-space schedulers with sched_ext, lock-holder preemption, and much more.

The 7.2 merge window started with the 7.1 kernel release on June 14. As of this writing, just over 7,000 non-merge changesets have been pulled into the mainline for the next kernel release. Many of the core subsystems have been pulled at this point, meaning that most of the changes that can be expected in 7.2 have now come into focus.

Version 4.6 of the Mastodon fediverse platform has been released.

The headliner of this release is Collections, a way to create and share curated collections of profiles. Part of Mastodon's work ethos is our commitment to trust and safety, so we've put a lot of thought and care into the design of this feature to avoid some of the pitfalls and abuse people have experienced with similar features on other platforms, while focusing on its primary goal: Helping new users discover more of the Fediverse.

Other new features include support for subscribing to posts via email, the ability to generate a "year in review" post, accessibility improvements, and more.

Part of running LWN is keeping a list of potentially interesting topics that may merit the effort to turn into articles. As an experiment, we are now exposing that list to our subscribers at the Project Leader and Supporter levels. The hope is that this list will provide useful insights into what is on our radar and which might be coming to LWN in the near future.

With this feature, we hope to give our most committed subscribers a look behind the curtain and the ability to provide input on the topics they are most interested in reading about. There, is, thus, a simple voting mechanism built into this list. No topic will be chosen (or rejected) solely on the basis of votes; there are a lot of considerations that go into topic selection, and that will not change. But more information about where our readers' interests lie will, hopefully, be helpful.

For all readers: we are always happy to welcome topic suggestions sent to lwn@lwn.net.

Linus Torvalds released the 7.1 kernel as expected on June 14. This development cycle brought in a lot of new features — and a lot of new developers as well. The time has come for our traditional look at where the changes in 7.1 came from, with a digression into how our community may be changing in general.

Linus has released the 7.1 kernel. "So it's only Sunday morning back home, but it's Sunday afternoon where I am right now, so I'm doing the 7.1 release at the regular time - just not in the regular timezone."

Significant changes in 7.1 include the removal of support for some old 486-based architectures, some new clone() flags making process management easier, BPF support for io_uring, zero-copy-I/O support for the ublk user-space block driver, initial (incomplete) sub-scheduler support in sched_ext, more swapping improvements, a completely rewritten NTFS implementation, and much more. See the LWN merge-window summaries (part 1, part 2) for details.

The Linux kernel has long tried to use huge pages as a way to improve performance, sometimes with more success than others. The size of huge pages has traditionally been imposed by the hardware, which typically only offers a couple of relatively large options. In more recent times, though, the use of multi-size transparent huge pages (mTHPs), with more flexible sizing implemented in software, has been growing. If all goes well, the 7.2 development cycle will include the addition of a new feature, contributed by Nico Pache, to make the use of mTHPs even more transparent.

Heise is carrying a report from the Linux App Summit, held in Berlin in May.

The slightly more than a dozen talks were symbolically framed between the opening keynote by systemd creator Lennart Poettering and the closing talk by Jorge Castro, initiator of the Universal Blue project, from which the modern Linux systems Bluefin and Bazzite emerged. Both Castro and Poettering call for a fundamental rethink of how Linux operating systems are delivered but pursue different approaches.

The 7.1-rc7 kernel prepatch is out for testing. Linus said: "Anyway, as things look now this is the last rc. Something can obviously always come up and force us to change that, but please give rc7 a whirl and keep testing for one more week."

Since the earliest days of Unix, two of the core process-oriented system calls have been fork(), which creates a child process as a copy of the parent, and exec(), which runs a new program in the place of the current one. In Linux kernels, those system calls are better known as clone() and execve(), but the core functionality remains the same. While there is elegance to this process-creation model, there are shortcomings as well. A recent proposal from Li Chen to add "spawn templates" to the kernel will not be accepted in its current form, but it may point the way toward a new process-creation primitive in the future.

The Software Engineering Radio podcast has put up an interview with graphics maintainer Dave Airlie. Much of what is in there will not be news to LWN readers, but it is an interesting overview of the life of a large-subsystem maintainer.

I was talking to a few of the Rust people, and I thought: these are very young people, these are a group of people in their 20s, maybe 30s, they are a younger cohort of developers than the people I am normally used to dealing with. I thought there was maybe a good way we could bring these groups together. I think that having young people coming into the kernel using Rust is valuable... So I thought that I should be supportive of bringing Rust into the kernel.