Security updates have been issued by AlmaLinux (container-tools:rhel8, kernel-rt, libreoffice, nodejs:22, nodejs:24, opentelemetry-collector, perl-HTTP-Daemon, and python-markdown), Debian (dpkg, imagemagick, and postfix), Fedora (betterleaks, docker-compose, firefox, helm, perl-Compress-Raw-Bzip2, perl-IO-Compress, perl-JavaScript-Minifier-XS, python-cramjam, python-fastar, python-pillow-jxl-plugin, python-rignore, and tor), Oracle (grafana, grafana-pcp, and ruby:4.0), Slackware (tftp), SUSE (gi-docgen, glibc, helm, helm3, json-c-devel, kubevirt-1.6, librpmbuild10, python313-dulwich, python313-lxml_html_clean, python313-openapi-spec-validator, and sdbootutil), and Ubuntu (ruby-addressable).

Conversations about the kernel's filesystem implementations often involve a layer called "iomap", but relatively few people can reliably say what iomap actually is. That is just the kind of gap that LWN exists to fill. In short, iomap handles the mapping between data in the filesystem space (identified by a file of interest, and an offset within that file) and in the storage space (which may be a memory location, or a set of blocks on a storage device). Using that mapping, iomap handles a long list of common, filesystem-related tasks, allowing a lot of boilerplate code to be removed from individual filesystem implementations.

The 7.2-rc2 kernel prepatch is out for testing. Linus said: "It's Sunday afternoon, and rc2 is out. Things look very normal - it's not a small rc2, but it's in line with recent releases, and slightly smaller than rc2 was in 7.1. Let's see how that all continues, but so far so good."

The kernel community (like many other free-software projects) has recently seen a large influx of patches developed with the assistance of large language models (LLMs). Those patches tend to come from developers who were previously unknown to the community. At the moment, though, the memory-management developers are evaluating two large patch sets, developed with LLM assistance, that were submitted by established and well-respected developers. The rather different reception accorded to that work may give insights into how LLM-generated contributions will be handled going forward.

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.