© xartdesign / 123RF.com

Linus Torvalds mag bei der Kernel-Versionierung keine Zahlen, die die Anzahl seiner Finger und Zehen überschreiten. Jetzt folgt also auf Kernel 6.19 folgerichtig die Ausgabe 7.0

Mitte April 2026 hat Linus Torvalds Linux 7.0 [1] freigegeben. Die neue Hauptversionsnummer bedeutet keinen architektonischen Umbruch, sondern ist aus Torvalds’ Sicht der nächste logische Schritt nach 6.19. Dennoch bündelt das Release eine Reihe nun gereifter Funktionen von stabilisiertem Rust über selbstheilendes XFS bis zu spürbaren Gewinnen beim Swapping und für Gamer.

Im Entwicklungszyklus 7.0 landeten 14 251 Commits, was im Schnitt der letzten Veröffentlichungen liegt. Dass die Beiträge von 2362 Entwicklern stammen ist weniger typisch und bricht den bisherigen Rekord (2134) deutlich. Auch die Zahl der Entwickler, die ihren ersten Beitrag zum Kernel leisteten, lag mit 489 weit über dem Langzeitdurchschnitt von 250 bis 350. Eine mögliche Erklärung für den Anstieg könnte das Absenken der Einstiegshürde durch die neuen KI-Richtlinien für die Kernel-Entwicklung sein, auf die wir noch näher eingehen. Für eine belastbare Einschätzung bleibt aber die weitere Entwicklung über die nächsten Kernel-Versionen abzuwarten.

Der Entwicklungsprozess zu Version 7.0 verlief nach Torvalds Aussage “etwas holpriger als üblich”. Das lag diesmal nicht an späten Einreichungen, die er kürzlich einmal mehr monierte. Vielmehr brachten KI-gestützte Codeanalyse-Tools eine ungewöhnlich hohe Zahl kleiner, bisher unentdeckter Bugs ans Licht. Torvalds bezeichnete diesen Zustand als mögliches “new normal”. Greg Kroah-Hartman, die Nummer 2 beim Kernel, berichtete in einem Interview [2], die Brauchbarkeit von KI-Tools zum Auffinden von Fehlern im Kernel-Code habe sich innerhalb weniger Monate enorm gesteigert.

Rust ist offiziell dabei

Seit Linux 6.1 gilt Rust als zweite offiziell zugelassene Kernel-Sprache. Doch bislang haftete dem Status stets der Zusatz experimentell an. Mit Linux 7.0 fällt der Vorbehalt. Das bedeutet nicht, dass der Kernel in Rust umgeschrieben und C verdrängt wird. C bleibt weiterhin die primäre Sprache. Was sich konsolidiert hat, ist der Reifegrad der Rust-Infrastruktur: Build-System, Abstraktions-Schichten, Dokumentation und Maintenance-Prozesse sind nun formal stabilisiert.

Künftige Treiber, Subsysteme oder sicherheitskritischer Code dürfen Rust dort einsetzen, wo es sich anbietet. Der Vorteil liegt auf der Hand: Buffer-Overflows, Use-after-free und Null-Pointer-Dereferenzierungen, die die häufigsten Quellen von Kernel-CVEs darstellen, schließt gut formulierter Rust-Code strukturell aus. Auf dem Linux Kernel Maintainers Summit 2025 endete eine lange Debatte mit dem klärenden Satz: “Rust is here to stay” [3]. Linux 7.0 setzt diesen Beschluss jetzt praktisch um.

Hardware-Unterstützung

Bei den Hardware-Auffrischungen zeigt Linux 7.0 die gewohnte Breite. Für kommende CPU-Generationen legt der neue Kernel den Grundstein. Intel Nova Lake [4] und die wohl erst 2027 erscheinende Datacenter-GPU Crescent Island, die für KI-Inferenz und hohe Energieeffizienz optimiert ist [5], bekommen initiale Unterstützung. Dazu bedurfte es zunächst der Veröffentlichung des Intel Graphics Compilers (IGC) in Version 2.27.10. Die für Mitte 2027 erwarteten Intel-Xeon-7-Serverprozessoren Diamond Rapids erhalten eine Performance Monitoring Unit (PMU) [6].

AMDs kommende Zen-6-Architektur erfährt grundlegende Funktionen wie CPU-ID-Erkennung, erweiterte Performance-Events und Metriken. Hinzu kommt frühe Unterstützung bei der x86-/Scheduler- und Perf-Infrastruktur. In Sachen Virtualisierung flossen Verbesserungen für KVM unter AMD Zen 5 ein, von denen auch Zen 6 profitiert.

Außerdem widmeten sich die Entwickler der chinesischen, von MIPS64 und RISC-V inspirierten CPU-Architektur LoongArch. Die Implementierung von HOTPLUG_SMT, das eine bessere Handhabung von Simultaneous Multithreading (SMT) ermöglicht, steht dafür. Ferner beherrscht der Kernel ab sofort 128-Bit Atomic Compare-and-Exchange (CMPXCHNG), was die Leistung bei parallelen Operationen steigert. Zusätzlich gibt es Aktualisierungen der Device-Tree-Dateien (dts), einschließlich Unterstützung für NAND-Controller. KVM erhält neue Funktionen speziell für LoongArch, um die Virtualisierungsleistung zu verbessern [7].

Als wichtigste Neuerung für ARM64 unter Linux 7.0 darf die Unterstützung von atomaren 64-Byte-Befehlen mit einmaliger Kopie (LS64/LS64V) gelten. Die mit ARM v8.7 eingeführten 64-Byte-Lade- und Speicherbefehle stehen dem Userspace über »/proc/cpuinfo« zur Verfügung [8].

Der neue Kernel bringt auch signifikante Verbesserungen für ARM64-Einplatinen-Computer (SBCs) mit Rockchip-SoCs. Die Aktualisierungen betreffen vor allem die Multimedia-Fähigkeiten, das Display-Handling und die Hardware-Unterstützung neuerer Chipsätze. Für die Chipsätze RK3576 und RK3588, die unter anderem im Orange Pi 5 Plus oder im Radxa Rock 5B stecken, stehen offizielle H.264- und H.265-Videodekoder bereit [9]. Initiale Unterstützung gibt es für den Budget- und Industrie-SoC Rockchip RK3506.

Dateisysteme

Linux 7.0 schließt mit einer neuen API im VFS unter anderem eine Lücke, die bisher verhinderte, dass Metadatenkorruption und I/O-Fehler bei Dateisystemen einheitlich an den Userspace gemeldet werden. Jedes Dateisystem löste das Problem auf seine eigene Weise, die Fehlerweiterleitung an »fanotify« war inkonsistent oder fehlte ganz. Die neue »fserror«-Infrastruktur bietet eine Schnittstelle, die es Dateisystemen ermöglicht, Metadatenkorruption und Datei-I/O-Fehler in eine Warteschlange zu stellen und geordnet an »fsnotify« zu übermitteln [10].

Der erste Nutznießer der neuen Infrastruktur ist XFS. Bisher reagierte es auf erkannte Metadatenkorruption mit einem unmittelbaren Shutdown. Der Administrator musste das Dateisystem aushängen und »xfs_repair« ausführen. Jetzt erhält XFS eine Health-Monitoring-Funktion, die in Verbindung mit der neuen Infrastruktur eine selbstheilende Reparatur im laufenden Betrieb erlaubt [11]. Nicht jede Beschädigung lässt sich so beheben, aber für Server heißt das: Viele Fehler sind zur Laufzeit reparabel.

Die neue API verhilft auch EXT4 zu einem besseren Fehler-Handling. Neu ist dafür das sysfs-Attribut »err_report_sec«, mit dem sich der Fehlermelde-Timer steuern lässt. Er definiert, wie oft eine Warnmeldung über festgestellte Inkonsistenzen im Dateisystem im Protokoll landet [12]. Standardmäßig protokolliert der Timer alle 24 Stunden eine Warnmeldung, doch mit diesem sysfs-Attribut lässt sich das nach Bedarf konfigurieren oder durch Setzen auf null deaktivieren. Während die neue API die strukturierte Fehlerübermittlung an Anwendungen im Userspace übernimmt, verwaltet »err_report_sec« die von EXT4 erzeugten herkömmlichen Kernel-Log-Meldungen.

EXT4 profitiert zudem von verbesserten parallelen Direct-I/O-Schreiboperationen, was sich bei gleichzeitig laufenden Backups, Build-Jobs oder Datenbankoperationen positiv auswirkt. Bei gleichzeitigen direkten I/O-Schreibvorgängen in mehrere Dateien gelingt die Leistungssteigerung durch Zurückstellen der Aufteilung noch nicht geschriebener Extents bis zum Abschluss der I/O-Vorgänge.

NFS bekommt einen dynamisch skalierbaren Thread-Pool und passt damit die Anzahl der Server-Threads automatisch an die aktuelle Systemlast an. Experimentell hinzugekommen steuert die POSIX-Zugriffskontrolle für NFS-Freigaben effizienter, wer auf welche Dateien zugreifen darf. Die speziellen Kernel-Dateisysteme »pidfs« und »nsfs« sind ab sofort wegen Sicherheitsbedenken nicht mehr über das Netzwerk exportierbar [13]. Das Protokoll NFS 4.1 ist standardmäßig aktiviert.

Btrfs erhält experimentelle Unterstützung für die Funktion »Remap-Tree«, eine neue Ebene zur Übersetzung logischer Blockadressen. Das gestattet Änderungen an Metadaten wie etwa Relocations, ohne dass Blöcke physisch verschoben oder neu zu schreiben sind, was den Bedarf an kontinuierlichem Copy-on-Write verringert. Zudem aktiviert Btrfs mit Linux 7.0 Direct I/O für Blockgrößen, die größer sind als die PageSize des Kernels [14].

Scheduler

Der auffälligste neue Baustein ist die per Restartable Sequences (RSEQ) realisierte Scheduler-Time Slice Extension. An ihr arbeitet der Entwickler seit rund zehn Jahren: Ein Thread kann dem Kernel signalisieren, dass er sich gerade in einem kritischen Abschnitt befindet und etwas mehr Zeit benötigt. Wenn der Kernel das erlaubt, bekommt der Thread zusätzliche CPU-Zeit, statt ihn mitten im Abschnitt aus dem CPU-Kontext zu verdrängen. Die Kernel-Doku [15] beschreibt dafür eine per-Thread-Aktivierung über »prctl()« und einen Mechanismus, bei dem der Kernel die Verlängerung nur unter passenden Bedingungen gewährt.

Eine weitere zentrale Änderung beim Scheduler betrifft Lazy Preemption als neue Option, während ältere Modi wie none und voluntary aus den unterstützten Optionen entfallen, was die Auswahl auf volle und verzögerte Präemption reduziert. Das soll den Scheduler [16] für die unterstützten Architekturen x86/x86_64, s390, RISC-V, POWER, LoongArch und ARM64 vereinfachen und bei gemischten Lasten eine bessere Balance zwischen Latenz und Durchsatz liefern. Alle Scheduler-Änderungen zu 7.0 fasst ein Git-Merge [17] zusammen.

Hybrid-CPUs mit Effizienz- und Leistungskernen – wie Intels Architekturen seit Alder Lake oder AMDs neueren Designs – verhilft ein überarbeiteter Scheduler-Pfad zu besserer Ausnutzung. Das System klassifiziert Kerne und Workloads präziser und weist rechenintensive Threads zuverlässiger den Leistungskernen zu.

Speicherverwaltung

Bei der Speicherverwaltung setzt der Kernel die Swap Table Phase II um. Phase I des Swap Table kam als neue Datenstruktur mit Linux-Kernel 6.18 an Bord. Kernel 7.0 bringt mit Phase II den Ausbau und die Konsolidierung der Swap-Pfade. Die zweite Ausbaustufe der neuen Swap-Infrastruktur soll das Einlesen aus dem Swap Cache vereinheitlichen, überflüssige Sonderpfade entfernen und die Flags im Swap-Code aufräumen.

Laut Kernel-Doku ist der Swap Table II eine pro-Cluster-Array-Struktur und damit näher an einer einfachen Index-Lookup-Logik als der bisherige XArray-Zugriff. Er ist dadurch lokaler und arbeitet schneller [18]. In Benchmarks mit Redis zeigte sich ein Geschwindigkeitsgewinn von rund 20 Prozent. Für Systeme, die regelmäßig unter Speicherdruck geraten und in der Folge aktiv swappen müssen, ist das eine spürbare Verbesserung.

Gaming beschleunigt

Seit Kernel 6.14 steckt der NTSYNC-Treiber im Kernel. Das Modul implementiert Windows-NT-Synchronisationsprimitive direkt im Kernel. Wine und Proton mussten die Primitive bisher im Userspace emulieren, was zu erheblichem CPU-Overhead bei Spielszenen führte, die intensiven Gebrauch von Multithreading machten. Jetzt gilt NTSYNC als stabile, ausgereifte Schnittstelle, auf die Proton 10.0 direkt setzt.

Abbildung 1: Spiele wie Cyberpunk 2077 profitieren von der stabilen NTSYNC-Schnittstelle. Quelle: CD Projekt Red

In CPU-lastigen Szenarien zeigen Benchmarks Verbesserungen der Bildrate von 15 bis 25 Prozent an, etwa in Cyberpunk 2077 und Microsoft Flight Simulator. Im Alltagsbetrieb unter Distributionen wie Bazzite, Nobara oder Steam OS lassen sich diese Zahlen direkt nachvollziehen.

Neue Richtlinien für KI

Die Frage, wie der Linux-Kernel mit KI-generierten Patches umgeht, beschäftigt die Community seit Monaten. Auf dem Linux Kernel Maintainers Summit im Dezember 2025 in Tokio stand das Thema prominent auf der Agenda. Kernel-Entwickler Sasha Levin diskutierte dort Richtlinien für den Einsatz von ML-Tools und LLMs in der Kernel-Entwicklung. Einigkeit herrschte darüber, dass menschliche Verantwortung für Patches zentral bleibt, rein maschinell erzeugte Beiträge unerwünscht sind und die Tool-Nutzung offengelegt werden muss.

Im April 2026 gossen die Verantwortlichen die Ergebnisse der Diskussion in eine neue Richtlinie, die KI-unterstützte Code-Beiträge explizit erlaubt – vorausgesetzt, die Entwickler halten strenge neue Transparenzregeln ein [19]. Mittlerweile stehen die neuen Richtlinien in der Kernel-Dokumentation [20]. Vermutlich taucht bei der rasanten Entwicklung der KI das Thema ab und zu wieder auf.

Fazit und Ausblick

Linux 7.0 entwickelt den Kernel an einigen Stellen konsequent weiter. Rust ist kein Experiment mehr. Von einer neuen API im VFS-Subsystem profitieren gleich mehrere Dateisysteme wie EXT4 oder XFS, das sich nun selbst reparieren kann. Der Scheduler versteht Hybrid-CPUs besser als zuvor und Spiele profitieren allgemein von stabilem NTSYNC.

Linux 7.1 erschien Anfang Juni 2026. In Sachen Hardware bringt er verbesserte Sensor- und Energieverwaltungs-Profile sowie gezielte Anpassungen für AMD-Ryzen-AI-Prozessoren. Bei den Dateisystemen erhält der exFAT-Treiber wichtige Stabilitäts- und Leistungs-Updates. Zudem profitiert der neue NTFS-Treiber von Geschwindigkeitsvorteilen. Verabschieden müssen wir uns ab Linux 7.1 von der Unterstützung für sehr alte CPUs. Dazu zählen Prozessoren der ab 1989 eingeführten i486-Generation sowie einige alte i586-Modelle [21]. (uba)