Linux 7.0 released – more than just a version number jump

Contents

The new version number of the Linux kernel feels like a small fanfare. We are now at 7.0. However, this has less to do with a major architectural overhaul or new features. Linus Torvalds is known for not particularly liking large numbers after the decimal point in a version number. Therefore, this time there is again a jump to a new major release, purely for the sake of better numbering.

However, if one didn't know better, some features in Linux 7.0 would certainly suggest a major release-worthy leap. After all, the newcomer to the kernel lineup promises self-healing file systems, robust code when allocating memory, and Rust as an official – not experimental – feature.

Rust remains

The “Rust for Linux” project has reached an important milestone. As maintainer Miguel Ojeda states in a commit to the development branch of Linux 7.0, the integration of the Rust programming language is no longer considered experimental. Literally, Rust is “here to stay.” This assessment is also supported by Linus Torvalds and other kernel developers.

Accordingly, the status of Rust support in the kernel has been adjusted. In the configuration interface (menuconfig), Rust is no longer listed as an experimental feature. This formally establishes the language in the mainline kernel.

Rust was first incorporated into the kernel in 2022 with Linux 6.1. At that time, support was essentially limited to a simple example module for “Hello, world!” Since then, the infrastructure has been continuously expanded, for example in the area of drivers and kernel interfaces.

Further expansion needed

Despite this progress, the Rust integration is still under expansion. Numerous subsystems currently offer only limited or no Rust interfaces. Accordingly, further adjustments and expansions are to be expected in upcoming kernel versions.

In parallel, Rust is already being used in other areas of the Linux ecosystem, for example in the Android environment. The development in the mainline kernel is thus part of an overarching trend towards memory-safe programming languages in system-level software.

With its move out of the experimental phase, Ojeda also wants to set a signal. Investments in Rust are on a secure foundation. In particular, efforts in training kernel developers in Rust are intended to be a safe investment. Nevertheless, Rust remains a bit of an exotic. The respective maintainers are free to keep Rust out of their subsystems in the kernel.

XFS: Self-monitoring instead of repair tool

With the introduction of “autonomous self-healing support,” XFS is evolving conceptually: away from a purely reactive file system towards an architecture that detects errors early and can react to them automatically. This is less about “self-healing” in the narrow sense and more about an intelligent division of tasks between the kernel and user space. So there's no magic dust involved.

Traditionally, error correction in XFS is done using tools like xfs_repair. Administrators start these manually, typically when a problem has already occurred – for example, after a crash or when inconsistencies in the file system are detected.

The process is clearly structured but also heavyweight: first, the file system must be unmounted, i.e., taken offline. This is followed by a complete analysis of the file system. Finally, all found errors are repaired.

This approach is reliable but has clear disadvantages: it causes downtime, reacts late to issues, and is time-consuming for large storage systems.

Event-based self-monitoring

The new “self-healing mechanism” follows a fundamentally different approach. Instead of fixing errors only after the fact, the kernel detects issues during operation and reports them to user space. An important principle applies here: the kernel detects and reports. However, the decision on what to do is made by user space.

Technically, this is done via an event system, for example, using file descriptors and ioctl. Through this, specialized programs continuously receive information about the state of the file system.

Daemons in User Space

A central component of this architecture is a user-space service (Healer Daemon). This evaluates incoming events and decides which actions are sensible. Typical reactions could be starting a targeted scrubbing process, initiating a partial repair, or restarting affected applications or containers. Escalation to monitoring or alerting systems would also be an option.

This makes error handling significantly more flexible and context-dependent. This promises a decisive advantage over rigid kernel mechanisms.

The difference between the classic and the new approach can be reduced to a fundamental shift: proactive rather than reactive. Previously, the system reacted to damage that had already occurred. The new approach, on the other hand, focuses on early detection and automated reaction. While xfs_repair serves more as an “emergency tool,” the self-healing approach is understood as a continuous monitoring and reaction system in the background.

Significance for modern systems

This development is particularly relevant for modern IT environments such as cloud infrastructures, container platforms like Kubernetes, and large, highly available storage systems. In such scenarios, downtime is at least expensive, if not unacceptable. Systems must be able to detect problems independently and fix them with minimal human intervention.

The new self-healing support in XFS does not (yet) replace classic repair tools but complements them meaningfully. While tools like xfs_repair remain necessary for serious cases, the new architecture enables a much earlier and finer reaction to issues. Thus, XFS is evolving into a file system that not only manages data but actively contributes to the stability of the overall system.

Type safety for old API

With Linux 7.0, one of the most central interfaces of the kernel undergoes a fundamental modernization: kmalloc(). This is not a complete redevelopment of memory management, but a targeted further development for more robust code. Typical sources of error in C programming are to be systematically avoided.

It's a well-known issue. Traditionally, kmalloc() works based on size; developers explicitly specify how many bytes should be allocated. Constructs like sizeof(...) are usually used. However, this flexibility comes at a price. Errors such as using sizeof(ptr) instead of sizeof(*ptr) are syntactically correct but lead to small allocations. The consequences at runtime can be severe. If the memory area is too small for the data to be stored, it overwrites others. A classic overflow is the result. Such bugs have been among the classic issue areas in the kernel for decades.

Object-based allocation

Linux 7.0 therefore introduces a series of new macros, including kmalloc_obj() and kmalloc_objs(). Instead of calculating the size manually, the developer describes the desired object type directly. The required memory size is derived automatically. At the same time, the compiler ensures that the return type and the target variable match.

This shift from a size-oriented to a type-based way of thinking not only increases code readability but also detects errors at compile time.

Another advancement concerns structures with a flexible array at the end. A commonly used pattern in the kernel. With kmalloc_flex(), a specialized macro is available in the new kernel that automatically calculates the correct total size of such objects. In combination with modern compiler extensions like __counted_by(), even the associated length specification can be set appropriately. This significantly reduces inconsistencies between memory size and metadata.

Less boilerplate, more security

In addition to type safety, usability has also been refined. In many cases, the previously mandatory allocation flag GFP_KERNEL can be omitted, as it is implicitly assumed. This reduces redundant code and makes typical allocations more compact and clearer.

The introduction of the new macros was not limited to new code paths. Large parts of the existing kernel were automatically adapted. The change is therefore less a point feature and more a broad quality improvement of the entire codebase.

The revision of kmalloc() in Linux 7.0 is a typical example of evolutionary kernel development. Instead of creating new functionality, the existing infrastructure is made safer and clearer. Through type-safe macros, better support for complex data structures, and reduced error susceptibility, the innovation contributes significantly to the long-term stability and maintainability of the Linux kernel.

Rest in peace, Laptop Mode

The new offspring of the Linux kernel is retiring Laptop Mode. This mode was added to the kernel in version 2.4 (as a backport, it officially arrived in 2.6.6). Over the years, it managed to squeeze a few more hours of battery life out of laptops. That's now over.

Laptop Mode in the Linux kernel is a power-saving feature primarily developed for systems with mechanical hard drives. It deliberately delays and bundles write accesses to the storage device, so the hard drive needs to be activated less often and can remain in its power-saving idle state for longer. Technically, this is achieved by adjustments in the kernel's writeback behavior (controllable via /proc/sys/vm/laptop_mode). The disadvantage is an increased risk of data loss in case of crashes, as data remains in RAM for longer.

On modern systems with SSDs, Laptop Mode plays hardly any role anymore. Since the days of internally installed mechanical hard drives are also over for modern notebooks, Laptop Mode is being removed from the kernel. The constant code maintenance for a feature that is no longer up-to-date is too complex.

SELinux keeps eBPF in check

The integration of eBPF into SELinux's security model extends the previously primarily technical security provided by the Verifier with comprehensive access control. In the Linux kernel, it is no longer just checked whether an eBPF program is safe, but also whether a process is even allowed to use it according to defined policies.

The core of the extension is the integration of eBPF into the Mandatory Access Control model. Processes require explicit permissions to load programs, attach to kernel hooks, or interact with existing BPF objects. At the same time, programs, maps, and other eBPF structures can be assigned their security contexts, allowing targeted restriction of access and data flows.

This combination of Verifier and SELinux creates a two-stage security concept: while the Verifier ensures the correctness of programs, SELinux controls their permissible use. This integrates eBPF much better into existing security architectures and makes it suitable for use in security-critical environments.

In summary

The new kernel again offers many new drivers and support for new hardware. There are also many detailed improvements, for example in eBPF and Rust. The self-healing in XFS and the improved kmalloc() alone mean that the new kernel can no longer be considered a mere “maintenance release.” This makes it worthy of a release jump to 7.0, even beyond Linus Torvalds' “phobia” of long numbers.

All changes in the new kernel can be found in the ChangeLog. Linux 7.0 is available for download as usual from www.kernel.org. The development of Kernel 7.0 was started by Linus Torvalds two weeks after Kernel 6.19 saw the light of day in early February 2026.

(mho)