Linux 6.19: results of the sixth branch and transition to 7.0. What’s new and what has changed?

By the way, immediately after this announcement, Linus Torvalds announced the transition to branch 7.0. Why and for what purpose? Let’s take a look.

What About Version Numbering

In the 6.19 announcement, Linus Torvalds stated that the next release will be 7.0. There was no technical necessity for this; the numbers in the 6.x series simply became too long, so he decided to start a new major branch. This has happened more than once before.

In 2015, after 3.19, version 4.0 was released, and in 2022, after 5.19, came 6.0. In both cases, it was merely a change in numbering, without any break in architecture or a sudden influx of new features. With the transition to 7.0, the situation is the same: the 6.x series has concluded, and development will continue within the framework of a new major version. The 7.0 release will be a normal phase of development with the usual merge window and standard change cycle.

The moment was chosen symbolically. The 6.19 release concluded several long-term experiments, including the integration of Rust. Now the language transitions to stable status as an official programming language. Additionally, the mechanism for complete kernel replacement without rebooting has been brought to a working state, and support for modern isolation methods in virtual environments has been expanded. These are no longer experimental features but full-fledged capabilities worth using in regular work.

Now, onto the updates

Linux 6.19 — a notable release with a significant number of very useful changes. The developers have updated the memory and input-output management mechanisms, strengthened security, optimized the network stack, and added support for new hardware. Many of these changes are not immediately noticeable, but they directly impact the stability, speed, and maintainability of the system. Let's take a closer look at what has been added and improved.

Live Updates: from Patches to Full Kernel Replacement

One of the most noticeable innovations in 6.19 is the Live Update Orchestrator (LUO) subsystem, built on the Kexec HandOver framework. It allows for a complete kernel replacement without stopping the system, maintaining the state of devices, memory, interrupts, and even DMA operations. Previously, live patching was limited to fixing individual vulnerabilities, but now there is the ability to update the entire kernel without interrupting application work.

In large data centers, rebooting thousands of machines for an update means hours of lost time and money. LUO addresses this issue at a new level, though the technology is still fresh and requires thorough testing. It is complemented by the klp-build script for convenient assembly of live patches and the updated objtool.

At the same time, other continuity mechanisms are being developed. For example, the audit subsystem has reduced overhead by almost half. QoS limits have been added for s2idle to restrict the waking of the processor while in standby mode. Even in zram, batch operations for write compression swap have appeared. These changes contribute to an overall picture: the kernel is increasingly oriented towards scenarios where high availability is critical.

io_uring: Further Development of Asynchronous I/O

The io_uring interface continues to receive enhancements that expand its capabilities. In 6.19, the Zero-Copy Receive mode was introduced: data from the network goes directly into the application buffer without unnecessary copying within the kernel. Support for variable size SQE has been added, along with new ring configuration options via IORING_SETUP_NO_MMAP, and the getsockname and getpeername operations directly through io_uring.

These improvements reduce latency and CPU load in high-load network services—from databases to container orchestrators. io_uring is gradually becoming a more versatile tool for asynchronous operations, although it does not completely replace traditional system calls. Development is progressing gradually, with compatibility being maintained.

In high-performance scenarios, such optimizations yield noticeable effects: fewer context switches, better utilization of hardware resources. io_uring has long been helping to bypass the limitations of classical interfaces, and each new addition reinforces its position as one of the key components of the modern kernel.

Security: Hardware Barriers and Cryptographic Enhancements

Security remains a priority, so version 6.19 introduced several significant innovations. Support for Intel LASS provides linear separation of address spaces, blocking speculative attacks at the hardware level. Similar mechanisms have been implemented for ARM through MPAM. An infrastructure for encrypting PCIe channels and authenticating devices in virtual machines with TDX and SEV-SNP has been added.

A separate block of changes concerns cryptography and software mechanisms. The library now includes SHA-3 in all variants, SHAKE, and BLAKE2b. A Confidential VMBus for Hyper-V has appeared—a secure communication channel between the guest and the hypervisor. Audit features have been improved, and scoped primitives have been added to prevent speculative reading of user data, along with pidfd signals in coredump.

All of this creates a multilayered defense: from low-level processor barriers to access policies. Such innovations are especially important in confidential computing and critical infrastructure, where data leakage is unacceptable.

Rust in the Kernel: The Experiment is Over

The Rust-for-Linux project has been ongoing for several years, and version 6.19 is no exception. Libraries for working with rbtree, pin-init, and numerical operations have been added. Abstractions for I2C and PWM drivers, macros for module parameters, and support for integer values have emerged.

With version 7.0, support for the language officially exits experimental status. It is not enabled by default, code in C remains the foundation, but new subsystems can already take advantage of Rust—primarily the guarantees of memory safety at compile time. This reduces the risk of vulnerabilities that have plagued C development for decades.

The transition is cautious: no one plans to rewrite the entire kernel. But the emergence of a second language in the stable branch is an important signal. What exactly? The project is becoming multilingual, attracting new developers, and simplifying the creation of safe drivers.

File Systems and I/O Subsystem

In version 6.19, many improvements were made to file systems. Btrfs now retains the state of scrub and device replace operations before sleeping to avoid blocking suspend. Integration with fscrypt has been prepared, and support for RAID56 for blocks larger than a page has been added. Ext4 has finally included them with more than 4 KB on x86—this provides up to a 50 percent increase in buffered writes.

FUSE has learned to work better with large folios during buffered reads, loading only the missing data. VFS received recallable delegation for directories in NFS. The I/O subsystem has enabled per-CPU bio caching by default—a noticeable performance boost.

These changes help the kernel handle modern storage devices better: from fast SSDs to distributed storage. Not only speed is important but also reliability and compatibility with energy-efficient modes. Development is moving towards greater flexibility and performance under real workloads.

Network Stack: Optimizations and New Protocols

Developers removed spinlocks in __dev_queue_xmit and switched to lockless llist. Under heavy traffic, this increases throughput and reduces CPU consumption. Support for CAN XL with a payload of up to 2048 bytes and the ability to tunnel Ethernet has been added.

A continuous busy polling mechanism in kernel threads for low-latency descriptor processing has appeared. New sockaddr_unsized with flexible arrays, additional sysctl for TCP receive buffers. All of this makes the kernel better prepared for modern networks—from data centers to industrial systems.

Optimizations affect critical paths, where every microsecond counts. The development of the network stack reflects the growing demands: more traffic, lower latency, higher reliability.

Hardware Support and Drivers

Drivers, as usual, accounted for a significant portion of the changes. The graphics subsystem introduced an API for hardware color conversion during HDR output. In AMDGPU, support for older cards based on the GCN 1.0/1.1 architecture was expanded — the Radeon HD 7000–9000 series received more modern functionality.

Drivers for Arm Ethos NPU, ASUS Armoury, and a number of new sound chips have been added. Support for boards and platforms on ARM and RISC-V has been expanded, including devices based on MediaTek and some Bananapi models. Work has also begun on the NVIDIA Nova driver in Rust.

Overall, the changes affect both desktop GPUs and embedded and specialized solutions — a typical kernel effort to expand hardware support.

Where the Kernel is Heading

Linux has long been used on servers and in infrastructure, and today its main workload consists of data centers, cloud platforms, networking equipment, and embedded systems. Therefore, the evolution of the kernel is largely tied to virtualization, isolation, high-density workloads, and support for various hardware.

In upcoming releases, work will continue in the same directions: “finishing touches” on live patching mechanisms, development of io_uring, strengthening support for RISC-V and other architectures, and improving energy-efficient mode handling. Security will be enhanced as new hardware capabilities in processors emerge.

And it’s worth repeating: the transition to 7.0 does not change anything in the development model by itself. The project continues to move forward at the same pace, with regular cycles and gradual changes without sharp turns. Have you updated yet? What do you think?