пальцы рук и ног закончились — начался седьмой десятокfingers and toes ran out — the seventh decade begins

Linux 7.x: текущая активная веткаLinux 7.x: the current active branch

Снова чисто нумерационный сброс — на этот раз с честной, почти буквальной причиной от самого Торвальдса. Внутри: Rust окончательно официален, XFS учится чинить себя сама, а модули ядра готовятся к постквантовой криптографии. Ветка активна прямо сейчас, страница будет дополняться по мере выхода новых минорных версий.Another purely numerical reset — this time with an honest, almost literal reason straight from Torvalds. Inside: Rust becomes officially permanent, XFS learns to heal itself, and kernel modules get ready for post-quantum cryptography. The branch is active right now — this page will be extended as new minor versions ship.

текущая веткаcurrent branch 2026 – настоящее время2026 – present

Что этоWhat it is

Ветка 7.x открылась 12 апреля 2026 (7.0.0) и на момент написания (август 2026) насчитывает уже три релиза — 7.0, 7.1 (14 июня 2026) и 7.2 (16 августа 2026), при активной разработке следующего, 7.3. Модель разработки не менялась шестой раз подряд с 2003 года — та же непрерывная схема из 2.6.0. Смена первой цифры с 6 на 7 не была вызвана техническим разрывом (см. закономерность, начавшуюся с 2.6→3.0): Торвальдс объяснил решение прямым текстом 8 февраля 2026 — «я начинаю путаться в больших числах (снова почти кончаются пальцы рук и ног), так что следующее ядро будет называться 7.0» — сохраняя собственную неформальную традицию завершать мажорную ветку около 19-й минорной версии, чтобы не оперировать неудобно большими числами.The 7.x branch opened April 12, 2026 (7.0.0) and, at the time of writing (August 2026), already counts three releases — 7.0, 7.1 (June 14, 2026), and 7.2 (August 16, 2026), with the next one, 7.3, under active development. The development model hasn't changed for the sixth time running since 2003 — the same continuous scheme from 2.6.0. The shift from 6 to 7 wasn't driven by a technical break (see the pattern that started with 2.6→3.0): Torvalds explained the decision in plain words on February 8, 2026 — "I'm getting to the point where I'm being confused by large numbers (almost running out of fingers and toes again), so the next kernel is going to be called 7.0" — keeping his own informal tradition of wrapping up a major branch around minor version 19 so the numbers stay countable.

версияversionдатаdateчто именно изменилосьwhat actually changed
7.0.02026-04-12Торвальдс сам назвал релиз «solid progress», а не прорывом: Rust окончательно переходит в стабильный статус (эксперимент завершён на Maintainers Summit 2025); self-healing XFS через демон xfs_healer, чинящий повреждённые метаданные без размонтирования; ML-DSA — постквантовые подписи для аутентификации модулей ядра взамен устаревающей схемы на SHA-1; упрощённая таблица подкачки (swap table) — второй этап переработки, ускоряющий память-интенсивные нагрузки; фильтрация в io_uring для более точного контроля разрешённых операций; стандартизированный API для сообщений о повреждении метаданных и ошибках I/O в userspace; поддержка статической проверки контекстов через новое расширение Clang (context locking); улучшенная производительность ext4 при параллельной прямой записиTorvalds himself called the release "solid progress" rather than a breakthrough: Rust finally moves to stable status (the experiment concluded at the 2025 Maintainers Summit); self-healing XFS via the xfs_healer daemon, repairing corrupted metadata without unmounting; ML-DSA — post-quantum signatures for kernel module authentication, replacing the aging SHA-1-based scheme; a simplified swap table — a second-phase rework speeding up memory-intensive workloads; io_uring filtering for tighter control over which operations a given opcode may perform; a standardized API for reporting metadata corruption and I/O errors to userspace; static context-checking support via a new Clang extension (context locking); improved ext4 performance for concurrent direct I/O writes
7.12026-06-14почти 13 000 изменений от более 2000 разработчиков — самый насыщенный цикл ветки на сегодня; полностью переписанный драйвер NTFS; Intel FRED (Flexible Return and Event Delivery) становится дефолтным механизмом для определённых системных переходов на поддерживаемом железе; ускорение futex-операций на ARM через новые инструкции; расширенные атрибуты для сокетов; BTF-информация для io_uring; поддержка суб-планировщиков внутри класса sched_extnearly 13,000 changes from over 2,000 developers — the branch's busiest cycle to date; a completely rewritten NTFS driver; Intel FRED (Flexible Return and Event Delivery) becomes the default mechanism for certain system transitions on supported hardware; faster futex operations on ARM via new instructions; extended attributes for sockets; BTF information for io_uring; support for sub-schedulers within the sched_ext class
7.22026-08-16cache-aware балансировка нагрузки в планировщике; начальная поддержка HDMI 2.1 FRL в драйвере AMDGPU; devres-управление ACPI notify handlers; ранняя поддержка CRI-платформы для Intel Xe; Rust добавляется для архитектуры S/390 (мейнфреймы IBM); библиотека zerocopy для Rust, упрощающая zero-cost работу с памятью; более справедливый GPU-планировщик; новые hwcaps для ARM64-расширений dpISA 2025 года; large folios включены по умолчанию для Btrfscache-aware load balancing in the scheduler; initial HDMI 2.1 FRL support in the AMDGPU driver; devres-based management of ACPI notify handlers; early CRI platform support for Intel Xe; Rust support added for the S/390 architecture (IBM mainframes); the zerocopy library for Rust, simplifying zero-cost memory manipulation; a "fairer" GPU scheduler; new hwcaps for the 2025 ARM64 dpISA extensions; large folios enabled by default for Btrfs
7.3в разработкеin developmentожидается серия патчей «flatten the pick», нацеленных на улучшение планирования применительно к игровым и латентно-чувствительным нагрузкам; релиз ещё не вышел на момент написания этой страницыthe "flatten the pick" patch series is expected, aimed at improving scheduling for gaming and latency-sensitive workloads; not yet released at the time this page was written

История: как это былоHistory: how it happened

01

Февраль 2026: снова заканчиваются пальцыFebruary 2026: running out of fingers again

8 февраля 2026 Торвальдс объявил в рассылке разработчиков ядра, что следующая версия будет называться не 6.19, а 7.0. Формулировка была почти дословным повторением объяснения, звучавшего при переходах 2.6→3.0 и 3.19→4.0: минорная цифра снова разрослась до неудобной величины. В этот раз Торвальдс выразился особенно образно — про путаницу в «больших числах» и «почти кончающиеся пальцы рук и ног», подтверждая неофициальную закономерность: ветки 5.x и 6.x обе закончились на 19-й минорной версии перед сбросом. Merge window для 7.0 открылось на следующий день, 9 февраля, первый релиз-кандидат вышел 22 февраля. Сам Торвальдс подчеркнул, что смена главной цифры версии не связана напрямую с содержанием изменений — 7.0 не задумывалась как архитектурный прорыв.On February 8, 2026, Torvalds announced on the kernel developer mailing list that the next version would be called not 6.19 but 7.0. The wording nearly echoed the explanations given at the 2.6→3.0 and 3.19→4.0 transitions: the minor number had again grown unwieldy. This time Torvalds put it especially vividly — confusion over "large numbers" and "almost running out of fingers and toes" — confirming an informal pattern: both the 5.x and 6.x branches had wrapped up at minor version 19 before resetting. The merge window for 7.0 opened the next day, February 9, with the first release candidate landing February 22. Torvalds himself stressed that the main version number change wasn't directly tied to the content of the changes — 7.0 wasn't conceived as an architectural breakthrough.

02

Апрель 2026: Rust официален, XFS учится лечить себя самаApril 2026: Rust goes official, XFS learns to heal itself

7.0 (12 апреля 2026) вышла с формулировкой самого Торвальдса «solid progress» — не прорыв, а последовательное продолжение. Наиболее символичной строкой стал формальный переход Rust в стабильный статус: статус эксперимента был снят ещё на Kernel Maintainers Summit в декабре 2025 (см. ветку 6.x), и 7.0 стала первым релизом, где это уже не временная оговорка в документации, а зафиксированный факт — Rust-драйверы и модули официально «первоклассные граждане» кодовой базы. Технически заметнее для эксплуатации оказалась self-healing XFS: новый демон xfs_healer следит за состоянием файловой системы в фоне и автоматически находит и чинит повреждённые метаданные без необходимости размонтировать раздел — раньше это требовало offline fsck и простоя. Отдельный, менее заметный публике, но стратегически важный шаг — ML-DSA, постквантовые подписи для проверки подлинности модулей ядра взамен устаревающей SHA-1-схемы. Практическая срочность здесь не гипотетическая: атаки класса «harvest now, decrypt later» уже сегодня собирают подписанные данные с расчётом взломать их постфактум, когда квантовые компьютеры станут достаточно мощными, — так что подготовка инфраструктуры подписи модулей ведётся заранее, а не по факту появления угрозы.7.0 (April 12, 2026) shipped with Torvalds's own description, "solid progress" — not a breakthrough, a steady continuation. The most symbolic line was Rust's formal move to stable status: the experimental tag had already been lifted at the December 2025 Kernel Maintainers Summit (see the 6.x branch), and 7.0 became the first release where that's no longer a temporary caveat in the docs but a settled fact — Rust drivers and modules are officially "first-class citizens" of the codebase. More operationally visible was self-healing XFS: a new xfs_healer daemon watches the filesystem's health in the background and automatically finds and repairs corrupted metadata without needing to unmount the partition — previously this required an offline fsck and downtime. A separate, less publicly visible but strategically important step was ML-DSA, post-quantum signatures for verifying kernel module authenticity, replacing the aging SHA-1-based scheme. The practical urgency here isn't hypothetical: "harvest now, decrypt later" attacks are already collecting signed data today, banking on breaking it once quantum computers become powerful enough — so the module-signing infrastructure is being prepared ahead of the threat materializing, not after.

03

Июнь 2026: самый насыщенный цикл ветки — переписанный NTFS и Intel FREDJune 2026: the branch's busiest cycle — a rewritten NTFS and Intel FRED

7.1 (14 июня 2026) собрала почти 13 тысяч изменений от свыше 2000 разработчиков — насыщенность, нехарактерная для «символического» релиза сразу после сброса нумерации, где обычно ожидается более спокойный темп. Главная практическая новость для пользователей, работающих с Windows-накопителями, — полностью переписанный драйвер NTFS. Отдельная архитектурная деталь: Intel FRED (Flexible Return and Event Delivery) стала дефолтным механизмом обработки определённых системных переходов на поддерживаемом железе — более быстрая и предсказуемая альтернатива классическому механизму прерываний/исключений x86 для новых процессоров. На ARM ускорились futex-операции за счёт новых процессорных инструкций — деталь, важная для производительности блокировок в высококонкурентных многопоточных сценариях.7.1 (June 14, 2026) gathered nearly 13,000 changes from over 2,000 developers — an intensity unusual for a "symbolic" release right after a numbering reset, where a calmer pace is typically expected. The main practical news for users working with Windows drives was a completely rewritten NTFS driver. A separate architectural detail: Intel FRED (Flexible Return and Event Delivery) became the default mechanism for handling certain system transitions on supported hardware — a faster, more predictable alternative to the classic x86 interrupt/exception mechanism on newer processors. On ARM, futex operations sped up through new processor instructions — a detail that matters for lock performance under highly contended multithreaded workloads.

04

Август 2026: Rust добирается до мейнфреймов, планировщик учится дружить с кешемAugust 2026: Rust reaches mainframes, the scheduler learns to be cache-friendly

7.2 (16 августа 2026, самый свежий релиз на момент написания) продолжила расширение зоны присутствия Rust — поддержка появилась даже для архитектуры S/390, на которой работают мейнфреймы IBM, вместе с библиотекой zerocopy, упрощающей операции с памятью без лишних копирований. В планировщике появилась cache-aware балансировка нагрузки — учёт того, в каком CPU-кеше уже «тёплые» данные задачи, при выборе, на какое ядро её перенести, а не только учёт свободной вычислительной мощности. Отдельно — large folios включены по умолчанию для Btrfs, продолжение многолетней линии оптимизации работы с памятью большими страницами вместо мелких 4 КБ-блоков.7.2 (August 16, 2026, the most recent release at the time of writing) continued expanding Rust's footprint — support arrived even for the S/390 architecture, which runs IBM mainframes, alongside the zerocopy library, simplifying memory operations without unnecessary copying. The scheduler gained cache-aware load balancing — factoring in which CPU cache already holds a task's "warm" data when deciding which core to move it to, not just which core has free compute capacity. Separately, large folios were enabled by default for Btrfs, continuing a years-long line of work optimizing memory handling through large pages instead of small 4 KB blocks.

Архитектура на сегодняшний деньArchitecture as of today

На момент 7.2 (август 2026) ядро продолжает линии, заложенные в 6.x, но доводит их до эксплуатационной зрелости: Rust больше не требует оговорки «экспериментально» нигде в дереве и уже добрался до мейнфреймовой архитектуры S/390; файловые системы (в первую очередь XFS) получают автономное самовосстановление вместо ручного офлайн-обслуживания; инфраструктура подписи модулей готовится к постквантовой угрозе заранее, а не реактивно. Модель разработки — та же непрерывная схема с 2.6.0, без единого отклонения за более чем двадцать лет. Ветка активна: следующий релиз, 7.3, уже анонсирован с фокусом на планировщик для игровых нагрузок.As of 7.2 (August 2026) the kernel continues the lines laid down in 6.x but pushes them toward operational maturity: Rust no longer needs an "experimental" caveat anywhere in the tree and has already reached the S/390 mainframe architecture; filesystems (XFS foremost) gain autonomous self-repair instead of manual offline maintenance; module-signing infrastructure is preparing for the post-quantum threat ahead of time rather than reactively. The development model remains the same continuous scheme from 2.6.0, without a single deviation in over twenty years. The branch is active: the next release, 7.3, has already been announced with a focus on the scheduler for gaming workloads.

Грабли и мифыGotchas & myths

«7.0 — революционный релиз, раз сменилась главная цифра» — нет, сам Торвальдс сказал обратное"7.0 must be revolutionary since the main number changed" — no, Torvalds said the opposite

Закономерность, повторяющаяся с 2.6→3.0 (2011), продолжается: смена первой цифры версии Linux почти никогда не сигнализирует архитектурный разрыв, а отражает исключительно нежелание Торвальдса оперировать неудобно большими минорными числами. 7.0 сам он охарактеризовал как «solid progress», а не прорыв — интереснее судить о содержании релиза по конкретному changelog, а не по тому, какая цифра стоит первой.The pattern repeating since 2.6→3.0 (2011) continues: a change in Linux's leading version digit almost never signals an architectural break — it purely reflects Torvalds not wanting to deal with unwieldy large minor numbers. He himself described 7.0 as "solid progress," not a breakthrough — it's far more informative to judge a release by its actual changelog than by which digit comes first.

Self-healing XFS не заменяет бэкапыSelf-healing XFS doesn't replace backups

xfs_healer чинит повреждённые метаданные файловой системы на лету — это не то же самое, что восстановление утраченных данных пользователя после серьёзного сбоя диска или логической ошибки приложения. Автоматическое исправление метаданных снижает эксплуатационные риски и время простоя, но не отменяет необходимость резервного копирования как отдельного слоя защиты.xfs_healer repairs corrupted filesystem metadata on the fly — that's not the same thing as recovering lost user data after a serious disk failure or a logical application error. Automatic metadata repair reduces operational risk and downtime, but it doesn't remove the need for backups as a separate layer of protection.

Эта страница описывает ветку в процессе — цифры устареютThis page describes a branch in progress — the numbers will age

В отличие от закрытых веток 1.x–6.x, где хронология зафиксирована, 7.x продолжает развиваться прямо сейчас: 7.3 ещё не вышла на момент написания, а следующие минорные версии появятся уже после этой страницы. При использовании материала стоит сверяться с более свежими источниками для всего, что вышло позже 7.2 (16 августа 2026).Unlike the closed 1.x–6.x branches, where the timeline is fixed, 7.x is still developing right now: 7.3 hadn't shipped yet at the time of writing, and further minor versions will appear after this page was written. When using this material, check more current sources for anything released after 7.2 (August 16, 2026).

ТерминыTerms

self-healing XFS / xfs_healerself-healing XFS / xfs_healer
способность файловой системы XFS самой находить и чинить повреждённые метаданные в фоновом режиме, без размонтирования раздела и без офлайн-проверки (fsck). Демон xfs_healer, появившийся в 7.0, следит за состоянием файловой системы во время её обычной работы: раньше исправление такого рода повреждений означало простой — раздел нужно было отмонтировать и прогнать через отдельную офлайн-утилиту проверки.the ability of the XFS filesystem to find and repair corrupted metadata on its own, in the background, without unmounting the partition and without an offline check (fsck). The xfs_healer daemon, introduced in 7.0, watches the filesystem's health while it keeps running normally: previously, fixing this kind of corruption meant downtime — the partition had to be unmounted and run through a separate offline checking tool.
метаданные файловой системыfilesystem metadata
служебная информация о файлах — имена, размеры, права доступа, расположение блоков данных на диске — отдельная от самого содержимого файлов. Именно метаданные, а не пользовательские данные, чинит на лету xfs_healer: повреждение метаданных мешает файловой системе понять, где что лежит, даже если содержимое файлов физически цело.the bookkeeping information about files — names, sizes, permissions, where a file's data blocks live on disk — kept separate from the file contents themselves. It's metadata, not user data, that xfs_healer repairs on the fly: corrupted metadata stops the filesystem from knowing where things are, even when the file contents are physically intact.
ML-DSA
Module-Lattice Digital Signature Algorithm — постквантовый алгоритм цифровой подписи, устойчивый к атакам гипотетических будущих квантовых компьютеров. В 7.0 заменил устаревающую схему на SHA-1 для проверки подлинности модулей ядра — то есть для подтверждения, что загружаемый в ядро код действительно от доверенного источника и не подделан.Module-Lattice Digital Signature Algorithm — a post-quantum digital-signature algorithm designed to resist attacks from hypothetical future quantum computers. In 7.0 it replaced the aging SHA-1-based scheme for authenticating kernel modules — that is, for confirming that code being loaded into the kernel really comes from a trusted source and hasn't been tampered with.
постквантовая криптографияpost-quantum cryptography
класс криптографических алгоритмов, спроектированных так, чтобы оставаться стойкими даже против квантовых компьютеров — которые, если станут достаточно мощными, смогут взломать многие широко используемые сегодня алгоритмы шифрования и подписи. ML-DSA, применённый в 7.0 для подписи модулей ядра, — конкретный пример такого алгоритма.a class of cryptographic algorithms designed to stay secure even against quantum computers — which, once powerful enough, would be able to break many encryption and signing algorithms widely used today. ML-DSA, adopted in 7.0 for signing kernel modules, is one concrete example of such an algorithm.
"harvest now, decrypt later"
стратегия атаки, при которой злоумышленник уже сегодня собирает и сохраняет зашифрованные или подписанные данные, рассчитывая расшифровать или подделать их позже — когда появятся достаточно мощные квантовые компьютеры. Именно эта угроза, не гипотетическая, а уже идущая сейчас, объясняет, зачем переход на постквантовые подписи модулей (ML-DSA) начался заранее, а не когда квантовые компьютеры реально появятся.an attack strategy where an adversary collects and stores encrypted or signed data today, betting on being able to decrypt or forge it later — once quantum computers become powerful enough. This threat, not hypothetical but already underway, is why the move to post-quantum module signing (ML-DSA) started ahead of time rather than after quantum computers actually arrive.
swap table
внутренняя структура данных ядра, отслеживающая, какие страницы памяти выгружены в область подкачки (swap) и куда именно. Упрощение этой таблицы в 7.0 — второй этап более широкой переработки, ускоряющий работу памяти-интенсивных нагрузок за счёт меньших накладных расходов на управление подкачкой.an internal kernel data structure tracking which memory pages have been swapped out to disk and exactly where. Simplifying this table in 7.0 was the second phase of a broader rework, speeding up memory-intensive workloads by cutting the overhead of managing swap.
io_uring фильтрацияio_uring filtering
возможность более тонко контролировать, какие именно операции разрешено выполнять через конкретный тип запроса (opcode) в io_uring — асинхронном интерфейсе ввода-вывода Linux (подробнее о самом io_uring — в глоссарии статьи о ветке 5.x). Фильтрация, добавленная в 7.0, сужает разрешённый набор действий для отдельных типов запросов, что полезно, например, для ограничения возможностей sandboxed-процессов.the ability to more precisely control which operations a given request type (opcode) is allowed to perform through io_uring — Linux's asynchronous I/O interface (see the 5.x branch glossary for more on io_uring itself). The filtering added in 7.0 narrows the set of permitted actions for individual request types, useful for example when restricting what a sandboxed process can do.
context locking (Clang)context locking (Clang)
расширение языка компилятора Clang, позволяющее статически — на этапе компиляции, ещё до запуска программы — проверять, что определённые предварительные условия (контексты, например удержание нужной блокировки) действительно соблюдены в нужных местах кода. Такая проверка помогает ловить целый класс багов до того, как код вообще попадёт в работающее ядро.a Clang language extension that lets the compiler statically verify — at compile time, before the program ever runs — that certain preconditions (contexts, such as holding the right lock) actually hold at the right places in the code. This kind of check catches a whole class of bugs before the code ever reaches a running kernel.
Intel FRED
Flexible Return and Event Delivery — новый механизм обработки прерываний и системных вызовов на современных процессорах Intel, более быстрый и предсказуемый, чем классический механизм x86. В 7.1 стал дефолтным механизмом для определённых системных переходов на поддерживаемом железе.Flexible Return and Event Delivery — a new mechanism for handling interrupts and system calls on modern Intel processors, faster and more predictable than the classic x86 mechanism. In 7.1 it became the default mechanism for certain system transitions on supported hardware.
futex
fast userspace mutex — механизм блокировки (мьютекс) в Linux, спроектированный так, чтобы в отсутствие конкуренции за ресурс работать полностью в пространстве пользователя, без обращения к ядру; обращение к ядру нужно только при реальном конфликте, когда один поток вынужден ждать другой. В 7.1 futex-операции на ARM ускорились за счёт новых процессорных инструкций — важно для производительности блокировок в высококонкурентных многопоточных сценариях.fast userspace mutex — a Linux locking mechanism designed to run entirely in user space when there's no contention for the resource, with no need to involve the kernel; the kernel only gets involved on an actual conflict, when one thread has to wait for another. In 7.1, futex operations on ARM got faster thanks to new processor instructions — a detail that matters for lock performance under highly contended multithreaded workloads.
BTF
BPF Type Format — формат описания типов данных для eBPF-программ, позволяющий им переносимо работать на разных версиях ядра, не завязываясь жёстко на конкретную структуру внутренних данных ядра, с которой была скомпилирована программа. В 7.1 BTF-информация появилась и для io_uring.BPF Type Format — a format for describing data types used by eBPF programs, letting them run portably across different kernel versions instead of being hard-tied to the exact internal kernel data layout they were compiled against. In 7.1, BTF information was extended to cover io_uring as well.
large folios
использование более крупных объединённых единиц управления памятью (folios) вместо стандартных мелких блоков по 4 КБ — снижает накладные расходы ядра на управление памятью, поскольку одной структурой описывается сразу большой непрерывный кусок данных вместо множества мелких. В 7.2 large folios включены по умолчанию для Btrfs.using larger, combined memory-management units (folios) instead of the standard small 4 KB blocks — this cuts the kernel's memory-management overhead, since one structure now describes a large contiguous chunk of data instead of many small ones. In 7.2, large folios were enabled by default for Btrfs.
cache-aware балансировка нагрузкиcache-aware load balancing
подход планировщика, при котором выбор процессорного ядра для переноса задачи учитывает не только свободную вычислительную мощность, но и то, в каком CPU-кеше уже находятся «тёплые» (недавно использованные) данные этой задачи. Перенос задачи на ядро с уже прогретым кешем дешевле, чем на свободное, но «холодное» ядро, где данные придётся заново подтягивать из памяти. Появилась в 7.2.a scheduler approach where choosing which CPU core to move a task to accounts not only for free compute capacity, but also for which CPU cache already holds that task's "warm" (recently used) data. Moving a task to a core whose cache is already warm is cheaper than moving it to a free but "cold" core, where the data would have to be pulled back in from memory. Introduced in 7.2.