|
|
Log in / Subscribe / Register

The first half of the 7.1 merge window

By Jonathan Corbet
April 16, 2026
The 7.1 merge window opened on April 12 with the release of the 7.0 kernel. Since then, 3,855 non-merge changesets have been pulled into the mainline repository for the next release. This merge window is thus just getting started, but there has still been a fair amount of interesting work moving into the mainline.

Some of the more interesting changes merged so far include:

Architecture-specific

  • The amd-pstate power-management subsystem has gained support for dynamic performance preference, changing the system's power-management behavior depending on whether the system is running on AC or battery power. See this commit for some documentation.
  • Support for some old and unused 486 subarchitectures (specifically M486, M486SX, and ELAN) has been removed.
  • Intel's Flexible Return and Event Delivery (FRED) "defines new control-flow transitions (generally between privilege levels) that replace existing transitions (such as event delivery through the IDT and return using IRET)." This feature has been supported since the 6.9 release but disabled by default; as of 7.1, FRED will, instead, be enabled by default.
  • Support for NVIDIA Tegra410 memory-latency performance-monitoring units has been added. See the documentation added in this commit and this commit for details.
  • The Arm 9.6 LSUI feature adds instructions allowing the kernel to access user-space memory without disabling the "privileged access never" mode first; 7.1 uses these instructions to accelerate futex operations.
  • Support for Arm's Memory Partitioning and Monitoring (MPAM) feature has been improved and exposed to user space. See Documentation/arch/arm64/mpam.rst for more information.
  • The BPF just-in-time compiler on PowerPC systems has improved, with support for private stacks, fsession support, indirect jumps, and more.
  • The s390 architecture has also gained BPF fsession support.

Core kernel

  • There are three new flags to the clone3() system call. CLONE_AUTOREAP causes a process to automatically reap itself on exit rather than becoming a zombie and waiting for the parent to do the work. CLONE_NNP sets the no new privileges flag on the newly created process. And CLONE_PIDFD_AUTOKILL will cause the created child to be killed immediately when the pidfd given to its parent is closed. See this article for more information on all of these flags.
  • There is a new file, import_ns, for each loaded module in its associated /sys/module directory; it shows which symbol namespaces the module in question has imported.
  • The io_uring subsystem has gained BPF support, allowing the main dispatch loop to be replaced by a BPF program.
  • The high-resolution-timer core has been substantially rewritten for better performance; see this merge log for details. Among other things, the improvements mean that the scheduler can use high-resolution timers with no performance loss relative to a scheduler using coarse timers.
  • The project to add proxy execution to the kernel continues with the merging of part of the donor migration patch set, which will eventually enable the movement of donor tasks between CPUs to facilitate the donation of CPU time to a lock holder. This work is not yet complete, but is getting closer.
  • The way stack liveness is tracked in the BPF verifier has changed, yielding much faster verification for many programs. See this merge log for more information.

Filesystems and block I/O

  • The new FSMOUNT_NAMESPACE option to fsmount() will cause a new namespace to be created to hold the newly mounted filesystem. The clone3() and unshare() system calls have also gained flags to return a new mount namespace containing only a single nullfs mount.
  • The kernel can now generate and verify T10 protection information at the filesystem level. The block layer has had this capability for a while, but moving it to the filesystems improves efficiency (especially for reads) and will facilitate the eventual addition of this support to io_uring.
  • The ublk user-space block driver has gained support for zero-copy I/O; this commit contains some documentation on how to use this feature, and this one provides a self-test for it.
  • SED-OPAL is a specification for self-encrypting block devices. Support for SED-OPAL has been enhanced by a number of rigorously undocumented ioctl() operations for single-user mode support; see this patch posting for an overview.
  • The Btrfs shutdown operation, which stops all I/O operations until the subject filesystem is unmounted, was added in 6.19; in 7.1, it will lose its "experimental" status and become generally available.
  • The exfat filesystem now supports pre-allocation with fallocate().
  • The CIFS client filesystem now supports the creation of temporary files with the O_TMPFILE option.

Hardware support

  • Networking: Spacemit DWMAC Ethernet controllers, Nuvoton MA35 series Ethernet controllers, and Microchip PIC64-HPSC/HX MDIO interfaces.

Networking

  • Unix-domain sockets created directly via socket() (as opposed to being accessed via a filesystem) have traditionally not supported extended attributes. As of 7.1, these sockets include support for the user.* extended-attribute space. As described in this merge log, the driving use case for this feature is the ability to annotate sockets with extended attributes to document the protocol that the endpoints expect to use.
  • UDP Lite support has been removed; this move was announced in 2023 after it became clear that nobody was actually using this feature. See this merge log for more information.
  • The ability to build IPv6 support as a module has been removed; this protocol is either built directly into the kernel or disabled altogether.

Security-related

  • A set of configuration options was added for the 6.12 release to control whether accesses to the /proc/PID/mem file could override memory permissions; by default, that overriding is allowed since that is what the kernel traditionally did. As of 7.1, though, the default will switch to PROC_MEM_FORCE_PTRACE, meaning that permissions can be overridden by an active ptrace() user but not otherwise.
  • There is a new set of security-module hooks meant to facilitate the implementation of policies for overlay filesystems. The documentation is evidently too secret for inclusion in the kernel, but this changelog gives an overview of the hooks.
  • There is also a new hook controlling access to Unix-domain sockets in the filesystem. The Landlock security module uses this hook to provide new policy options for those sockets.
  • The growing, meticulously undocumented libcrypto library, which provides faster and easier access to cryptographic algorithms than the kernel's older crypto subsystem, has gained support for a number of new algorithms; see this merge message for a list.

Internal kernel changes

  • The i_ino field of the inode structure is now 64 bits wide on all architectures.
  • The way that symbols exported to modules are represented in the kernel binary has changed to a more efficient format.
  • The minimum version of Rust needed to build the kernel is now 1.85.0 (and bindgen 0.71.1); this change follows the decision made at the 2025 Maintainers Summit to require the versions provided by the latest Debian stable release. See the pull request for other Rust-related changes.
  • The kernel-doc tool, which is used to build the kernel documentation from comments in the code, has been significantly rewritten to use a proper C tokenizer and fewer gnarly regular expressions.
  • There have been a number of improvements around correct lock usage, including the addition of support for context analysis (formerly capability analysis) for rwsems, mutexes, and rtmutexes.

As of this writing, there are still nearly 9,000 non-merge changesets waiting to move from linux-next into the mainline, so expect to see a lot more interesting material in this development cycle. If the usual schedule holds, this merge window can be expected to close on April 26; tune in after that for a look at what all those changesets brought in.

Index entries for this article
KernelReleases/7.1


to post comments

lib/crypto/

Posted Apr 16, 2026 16:13 UTC (Thu) by ebiggers (subscriber, #130760) [Link] (4 responses)

> The ... meticulously undocumented libcrypto library

This characterization seems a bit unfair, considering that all the new functions have kerneldoc. Perhaps you were looking for a libcrypto.rst file? We'll add that at some point, but there's actually not much information that could go there. That's kind of the point. These are just library functions that implement each of the algorithms for internal use by the kernel, and using standard conventions (e.g. KUnit). So unlike the traditional crypto API where's a complex architecture that developers have to understand, with the library functions there's not a whole lot to add on top of the kerneldoc itself.

Or maybe this is as simple as the kerneldoc not having corresponding `.. kernel-doc::` directives in Documentation/ to make it appear in the HTML documentation, which made it get overlooked?

lib/crypto/

Posted Apr 17, 2026 7:02 UTC (Fri) by ebiggers (subscriber, #130760) [Link]

lib/crypto/

Posted Apr 17, 2026 13:27 UTC (Fri) by koverstreet (✭ supporter ✭, #4296) [Link] (2 responses)

Of all the places in the kernel to complain about lack of documentation, lib/crypto does seem like an odd one :)

lib/crypto/

Posted Apr 17, 2026 14:41 UTC (Fri) by corbet (editor, #1) [Link] (1 responses)

Trust me, I complain about the lack of documentation in many places...

lib/crypto/

Posted Apr 17, 2026 22:05 UTC (Fri) by Slumberthud (subscriber, #45657) [Link]

Indeed you do, and I suspect it was you who coined the term "rigorously undocumented" :)

Static analysis blogs

Posted May 7, 2026 3:25 UTC (Thu) by vtjnash (subscriber, #141755) [Link]

> number of improvements around correct lock usage, including the addition of support for context analysis

Is there anywhere to find out more about what these improvements are?


Copyright © 2026, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds