Noyau Linux 7.1 : nouveautés pour les serveurs

Nouveautés du noyau Linux 7.1

Le noyau Linux 7.1 est sorti le 14 juin 2026, neuf semaines après la version 7.0. Pour un utilisateur de VPS (virtual private server), les changements importants concernent quatre domaines : le stockage et les systèmes de fichiers, le réseau, la gestion de la mémoire, ainsi que le contrôle des processus et des conteneurs. Le reste de la version concerne principalement le bureau et les graphiques, que les serveurs headless ne chargent jamais.

Il faut d’abord apporter une deuxième précision. Le noyau 7.1 n’est presque certainement pas utilisé sur votre serveur et ne le sera pas avant longtemps. kernel.org ne classe pas 7.1 parmi les versions longterm. Au 11 août 2026, les branches longterm sont 6.18, 6.12, 6.6, 6.1, 5.15 et 5.10. Les principales distributions serveur s’appuient sur l’une de ces branches ou sur une branche qu’elles maintiennent elles-mêmes. Les nouveautés du noyau et les nouveautés réellement disponibles sur votre serveur peuvent être séparées de plusieurs années. Ce guide couvre donc les deux aspects.

Quel kernel votre VPS exécute-t-il actuellement

uname -r
uname -srm
systemd-detect-virt

uname -r affiche la release du kernel en cours d’exécution. Sur Ubuntu 24.04, elle ressemble à 6.8.0-79-generic. La partie située avant le premier tiret correspond à la branche upstream. Tout ce qui suit est le numéro de build propre à votre distribution et ne suit pas du tout l’upstream. Le 6.8.0-79 de Canonical contient des milliers de correctifs rétroportés depuis des kernels plus récents. Il ne s’agit donc pas du code que Linus a marqué comme 6.8 en mars 2024. C’est pourquoi dire « mon kernel est ancien » est moins significatif qu’il n’y paraît. Les fonctionnalités sont anciennes. Les correctifs de sécurité ne le sont généralement pas.

systemd-detect-virt vous indique si vous pouvez modifier le kernel. La commande affiche kvm sur une machine virtuelle complète, qui démarre sa propre image de kernel et pour laquelle une mise à niveau constitue une véritable mise à niveau. Elle affiche lxc ou openvz avec la virtualisation par conteneurs, qui partagent le kernel de l’hôte. Avec une offre de conteneur, uname -r affiche le kernel du fournisseur. Installer un package de kernel ne change rien à ce que vous pouvez démarrer, et aucune fonctionnalité de cette release ne vous est accessible tant que le fournisseur n’a pas redémarré l’hôte avec un kernel plus récent. Effectuez cette vérification avant de planifier toute opération sur le kernel.

[
  {
    "distro": "Ubuntu 26.04 LTS (7.0)",
    "releases_behind_7_1": 1,
    "notes": "GA kernel, shipped with the April 2026 release"
  },
  {
    "distro": "Ubuntu 24.04 LTS, HWE (6.17)",
    "releases_behind_7_1": 4,
    "notes": "6.17 came with 24.04.4; 7.0 is rolling out ahead of 24.04.5 on 27 August 2026"
  },
  {
    "distro": "Debian 13 trixie (6.12)",
    "releases_behind_7_1": 9,
    "notes": "upstream longterm line, kernel.org projected EOL December 2028"
  },
  {
    "distro": "RHEL 10 and its rebuilds (6.12)",
    "releases_behind_7_1": 9,
    "notes": "Red Hat backports fixes into its own frozen 6.12 stream"
  },
  {
    "distro": "Ubuntu 24.04 LTS, GA (6.8)",
    "releases_behind_7_1": 13,
    "notes": "the default unless you install the HWE stack"
  },
  {
    "distro": "Ubuntu 22.04 LTS, GA (5.15)",
    "releases_behind_7_1": 26,
    "notes": "upstream longterm line, kernel.org projected EOL December 2026"
  }
]

Cela représente 6 plateformes, et aucune ne démarre avec 7.1. La plus récente est Ubuntu 26.04 LTS (7.0), qui a 1 release upstream de retard. La plus ancienne encore supportée a 26 releases de retard. Le kernel GA par défaut d’Ubuntu 24.04 a 13 releases de retard, tandis que Debian 13 et RHEL 10 ont 9 releases de retard sur la branche longterm 6.12. Compter les releases fournit une mesure approximative, car cela ne tient pas compte de tout ce que les distributions rétroportent. Cela montre toutefois l’ampleur de l’écart. Si vous hésitez entre ces options, le compromis entre une release LTS et une release intermédiaire sur un serveur est la décision qui se trouve derrière ces chiffres.

Stockage et systèmes de fichiers dans 7.1

7.1 permet de générer et de vérifier les T10 PI (informations de protection) dans le système de fichiers, et plus seulement dans la couche de blocs. Il ajoute également la prise en charge d’un alignement T10 flexible. Les T10 PI sont des octets supplémentaires associés à chaque bloc. Ils contiennent une somme de contrôle et un tag qui identifie le bloc auquel les données appartiennent. Une écriture mal orientée ou partiellement effectuée est ainsi détectée au lieu d’être renvoyée comme une donnée valide. Pour un locataire VPS, le matériel constitue toutefois la limite. Les métadonnées d’intégrité doivent être exposées par le périphérique, ce qu’un disque virtuel ne fait généralement pas.

ls /sys/block/vda/integrity/

Sur la plupart des disques VPS, cela renvoie No such file or directory, car la couche de blocs ne crée le répertoire integrity que lorsque le périphérique enregistre la prise en charge de l’intégrité. Cette erreur est la réponse normale dans ce cas. Elle n’indique pas une panne. Si vous voulez connaître la nature réelle de votre disque avant d’aller plus loin dans les fonctions de stockage, commencez par vérifier si le disque VPS est réellement NVMe. La différence entre un SSD NVMe et un SSD SATA sur un VPS explique pourquoi le résultat modifie vos chiffres.

Btrfs corrige l’amplification du copy-on-write sous pression mémoire. Il accélère également l’effacement du premier extent dans une plage suivie. Le merge indique un gain de débit de 10 % sur la charge de travail utilisée pour le test. L’opération d’arrêt n’est plus marquée comme expérimentale. XFS améliore le flush des plages mises à zéro et la recherche via iomap. Il ajoute aussi un pointeur d’écriture à la géométrie des groupes real-time, ce qui prépare la prise en charge des périphériques zonés. NTFS est entièrement réécrit dans cette version. Il prend désormais complètement en charge l’écriture et utilise iomap. Cela peut être utile si vous montez sur votre serveur une image disque provenant d’une machine Windows.

Autres changements de stockage à connaître : ublk, le pilote de blocs en espace utilisateur, prend désormais en charge les E/S zero-copy ; io_uring prend en charge les commandes SCSI passthrough ; la prise en charge des disques autochiffrants SED-OPAL ajoute la commande STACK_RESET et étend le single user mode ; un nouveau pilote de caractères fs-dax est disponible pour les périphériques à accès direct ; et le VFS a élargi inode->i_ino de unsigned long à u64, ce qui supprime la limite du numéro d’inode dans les builds 32 bits. Du côté des systèmes de fichiers réseau, le serveur NFS du kernel peut désormais signer ses file handles avec une option de montage sign_fh, et le client CIFS prend en charge O_TMPFILE.

Réseau : location de files et apport pour les conteneurs

La principale évolution réseau concerne la location de files matérielles. Un périphérique réseau virtuel peut désormais louer une file liée à une file réelle d’un périphérique réseau physique et servir de proxy pour celle-ci. Cette fonctionnalité vise les conteneurs. Jusqu’à présent, un conteneur qui voulait utiliser AF_XDP (address family express data path, le type de socket qui transmet les paquets bruts à l’espace utilisateur sans les recopier à travers la pile réseau) devait recevoir quelque chose qui s’approchait de l’intégralité du périphérique. Avec une file louée, il obtient une file matérielle, exécute AF_XDP et les memory providers à vitesse native, tandis que l’hôte conserve le reste de la NIC. Cette fonctionnalité arrive en complément de la prise en charge d’AF_XDP dans le chemin zero-copy d’io_uring.

Dans le cas courant, les sockets de sockfs acceptent désormais les attributs étendus user.*. Un socket AF_UNIX fondé sur un chemin héritait déjà de la prise en charge des xattr du système de fichiers sous-jacent, mais un socket présent uniquement dans sockfs n’en disposait pas. Un processus peut maintenant étiqueter un socket, et un programme eBPF peut filtrer selon cette étiquette.

Deux suppressions. UDP-Lite disparaît, faute d’utilisateurs. IPv6 ne peut plus être compilé comme module chargeable : si vous voulez IPv6, il est intégré au noyau. Cette seconde modification est invisible dans les noyaux fournis par les distributions, car les distributions serveur courantes compilent déjà IPv6 en dur.

Gestion de la mémoire : la table de swap est terminée

La refonte de la swap atteint sa troisième phase, qui supprime la table de swap statique. Le nombre de pages de swap réside désormais directement dans la table de swap. L’économie annoncée représente environ 30 % des métadonnées statiques de la swap. Le kernel conserve ces métadonnées en fonction de la taille de votre périphérique de swap, qu’une partie soit utilisée ou non. En valeur absolue, l’économie reste faible avec un petit fichier de swap. Elle augmente avec la taille de la swap configurée.

MGLRU (multi-generational least recently used, le nouvel algorithme de récupération des pages) peut désormais vérifier le flag young des pages par lots, au lieu de traiter une page à la fois. L’amélioration publiée dépasse 60 % sur un serveur Arm64 à 32 cores. Le traitement par lots est surtout efficace lorsque le coût par page est élevé. C’est pourquoi cette valeur a été mesurée sur une grande machine Arm. Si vous utilisez un VPS Arm plutôt qu’un VPS x86, c’est probablement la modification de 7.1 qui apparaîtra le plus clairement dans vos propres mesures, même si les résultats seront moins élevés sur deux ou quatre cores.

Cette version inclut également la suppression des transferts depuis les memory cgroups en cours de suppression, une réduction de la consommation CPU de khugepaged et une importante refactorisation de la gestion des gros nœuds dans le maple tree. Vous ne configurez aucun de ces changements. Vous les constatez par une légère baisse du temps système.

Ordonnanceurs : sous-ordonnanceurs sched_ext et FRED activé par défaut

sched_ext, la classe d’ordonnanceur extensible qui permet d’écrire un ordonnanceur CPU sous forme de programme BPF et de le charger à l’exécution, est arrivé dans la version 6.12. La version 7.1 ajoute la structure de base des sous-ordonnanceurs, afin qu’un groupe de contrôle puisse à terme utiliser son propre ordonnanceur. Lisez attentivement cette phrase. L’implémentation n’est pas terminée dans la version 7.1. Le chemin d’enqueue, en particulier, est encore absent. Il s’agit donc d’un travail préparatoire pour une version ultérieure, et non d’une fonction que vous pouvez activer aujourd’hui.

Intel FRED (flexible return and event delivery) est désormais activé par défaut sur le matériel compatible. FRED remplace l’ancien chemin de distribution des événements x86 par une implémentation plus propre. Il est présent dans le noyau depuis la version 6.9, mais devait être activé avec l’argument de boot fred=on. Son activation par défaut indique que le matériel commercial a été suffisamment testé. Les mesures publiées jusqu’à présent, comprises entre 4% et 7% pour des charges fortement orientées E/S, proviennent de tests Phoronix réalisés sur du matériel client. Ne prévoyez donc pas ces gains sur un serveur avant d’avoir mesuré votre propre charge.

L’exécution par procuration prend désormais en charge la migration du donateur pour accélérer le propriétaire distant d’un verrou. EEVDF corrige plusieurs problèmes liés au retard négatif. Le cœur des timers haute résolution a aussi été largement réécrit. Ces changements améliorent la latence, mais aucun fichier de configuration ne permet de les contrôler.

Nouveaux contrôles des processus et des conteneurs dans clone3()

Trois indicateurs ont été ajoutés à clone3(). Chacun comble une lacune que les superviseurs contournent manuellement depuis des années. CLONE_AUTOREAP fait en sorte que le processus enfant se réapprenne lui-même à sa terminaison. Il ne devient donc jamais un zombie en attendant un parent qui pourrait ne jamais appeler wait(). CLONE_NNP active no_new_privs sur l’enfant au moment de sa création. Cela supprime la fenêtre entre l’appel à clone et l’activation de l’indicateur par l’enfant lui-même. CLONE_PIDFD_AUTOKILL lie la durée de vie de l’enfant au pidfd renvoyé au parent. Lorsque le pidfd est fermé, l’enfant est tué. Un superviseur qui s’arrête ne peut donc pas laisser de processus orphelins en cours d’exécution.

Les mount namespaces bénéficient du même traitement. CLONE_EMPTY_MNTNS pour clone3() et UNSHARE_EMPTY_MNTNS pour unshare() créent un mount namespace vide, au lieu d’effectuer la copie complète habituelle des montages du parent, que le runtime doit ensuite démonter. FSMOUNT_NAMESPACE permet à fsmount() de placer directement un filesystem dans un nouveau namespace. Les runtimes de conteneurs construisent cette configuration manuellement depuis dix ans. Le faire en un seul appel signifie qu’un runtime ne démarre plus avec un namespace rempli des montages de l’hôte.

Du côté de la virtualisation, guest_memfd prend désormais en charge userfaultfd. Un hyperviseur peut ainsi gérer les page faults du guest depuis l’espace utilisateur. KVM protégé sur Arm prend désormais en charge la mémoire anonyme. Le commit de fusion précise toutefois que cette fonctionnalité n’est pas prête pour la production.

Quand le noyau 7.1 arrive-t-il sur votre serveur

Fedora l’a déjà. Le dépôt de mises à jour de Fedora 44 est passé à la série 7.1 en juillet et août 2026, car Fedora rebase son noyau sur de nouvelles branches stables pendant la durée d’une version. Arch et openSUSE Tumbleweed l’ont pour la même raison. Ce sont des machines de test, pas des machines destinées à exécuter vos services.

Toutes les autres distributions attendent, et cette attente est volontaire. Debian 13 est sortie avec 6.12 et reste sur 6.12 pendant toute la durée de vie de la version, avec des correctifs rétroportés. RHEL 10 est sortie avec 6.12.0 et applique la même approche. Ubuntu 26.04 LTS est sortie avec 7.0 en avril 2026. Ubuntu 24.04 LTS dispose d’une pile d’activation matérielle (HWE), qui récupère un noyau plus récent des versions ultérieures d’Ubuntu pour l’intégrer à la LTS. Cette pile est en 6.17 depuis la version intermédiaire 24.04.4. Elle doit passer à 7.0 avec 24.04.5, prévue le 27 août 2026.

Voici l’erreur la plus fréquente. Une pile HWE passe au noyau fourni par la version intermédiaire la plus récente. Elle peut donc sauter complètement une branche amont. 7.0 est inclus dans une Ubuntu LTS. 7.1 ne sera peut-être jamais la base d’une LTS, car la version intermédiaire suivante fournira une branche plus récente. Les éléments issus de 7.1 qui arrivent dans votre LTS sont les correctifs, rétroportés dans la branche que vous utilisez. Les fonctionnalités restent pour l’essentiel dans la branche amont.

Si vous voulez vraiment un noyau plus récent sur un serveur stable, les options prises en charge sont limitées.

# Ubuntu 24.04 LTS: install the hardware enablement stack
sudo apt update
sudo apt install --install-recommends linux-generic-hwe-24.04
sudo reboot

# Debian 13, with trixie-backports enabled in your apt sources
apt-cache policy linux-image-amd64
sudo apt install -t trixie-backports linux-image-amd64
sudo reboot

Après le redémarrage, vérifiez le noyau effectivement démarré :

uname -r
dpkg -l 'linux-image-*' | grep ^ii
ls /var/run/reboot-required

uname -r doit maintenant afficher la nouvelle branche, et dpkg -l affiche toutes les images de noyau encore installées. Si uname -r affiche l’ancienne version alors que dpkg -l répertorie la nouvelle, le paquet a été installé, mais la valeur par défaut du bootloader n’a pas changé : vérifiez les entrées du menu GRUB. La présence de /var/run/reboot-required signifie qu’un paquet a mis à niveau le noyau et qu’aucun redémarrage n’a eu lieu depuis. C’est la raison la plus fréquente pour laquelle un serveur corrigé exécute encore le code vulnérable.

Faut-il viser la version 7.1 sur un VPS de production

Non. La raison n’est pas la prudence pour la prudence. Le kernel d’une distribution s’accompagne d’un contrat de support. Canonical, Red Hat, SUSE et Debian rétroportent chacun les correctifs de sécurité dans leur branche figée et les testent avec l’espace utilisateur fourni avec cette branche. Un kernel mainline provenant d’une archive tierce ou compilé manuellement vous apporte les nouvelles fonctionnalités, mais vous prive de ce travail, car personne ne rétroporte les correctifs dans votre build. Vous devenez le mainteneur d’un kernel.

Les exceptions existent, mais elles sont limitées : un matériel que l’ancien kernel ne sait pas piloter, ou une modification des performances que vous avez mesurée sur votre propre charge de travail et que vous souhaitez suffisamment pour en assumer les conséquences. Sur un VPS, le premier cas est presque inexistant, car le matériel visible est virtuel. Pour tout le reste, gardez le kernel de la distribution à jour et redémarrez lorsqu’il le demande. Si une mise à niveau de la distribution figure déjà dans votre liste, passer d’Ubuntu 24.04 à 26.04 vous fait passer de 6.8 à 7.0 en une seule étape, ce qui représente un saut plus important que celui fourni par n’importe quel paquet de kernel isolé.

FAQ

Comment vérifier le noyau Linux utilisé par mon VPS ?

Exécutez uname -r. La commande affiche une valeur semblable à 6.8.0-79-generic. Le nombre placé avant le premier tiret correspond à la branche upstream sur laquelle votre distribution s’appuie. Tout ce qui suit correspond au numéro de build propre à la distribution, qui intègre des correctifs backportés. Exécutez ensuite systemd-detect-virt. Si la commande affiche lxc ou openvz, vous utilisez une virtualisation par conteneur. Vous partagez le noyau de l’hôte et vous ne pouvez pas le modifier. Si elle affiche kvm, vous démarrez votre propre image de noyau et c’est à vous d’effectuer les mises à niveau.

Linux 7.1 est-il un noyau avec support à long terme ?

Non. Au 11 août 2026, les branches longterm indiquées sur kernel.org sont 6.18, 6.12, 6.6, 6.1, 5.15 et 5.10. La version 7.1 n’en fait pas partie. Il s’agit d’une version stable standard. Sa branche stable est abandonnée peu après la publication de la version mainline suivante. Si vous voulez un noyau bénéficiant de plusieurs années de correctifs déjà publiés et de plusieurs années de correctifs à venir, c’est déjà le rôle du noyau fourni par votre distribution.

Quand Ubuntu ou Debian fourniront-ils le noyau 7.1 ?

Probablement jamais par défaut. Debian 13 reste en version 6.12 pendant toute la durée de vie de cette release, et RHEL 10 reste en version 6.12.0. Ubuntu 26.04 LTS a fourni la version 7.0. Une stack Ubuntu hardware enablement passe à la version de noyau utilisée par la dernière interim release. Elle peut donc ignorer entièrement une branche upstream. Ubuntu 24.04 LTS doit faire passer son noyau HWE à la version 7.0 avec la point release 24.04.5, prévue le 27 août 2026. Les correctifs de la version 7.1 vous parviendront sous forme de backports dans une branche plus ancienne. Les fonctionnalités, en général, ne seront pas backportées.

Qu’est-ce qui compte réellement dans Linux 7.1 pour un serveur privé virtuel ?

Quatre éléments. Le leasing des queues matérielles permet à un conteneur d’utiliser une queue réelle de NIC pour AF_XDP à vitesse native. La troisième phase de la refonte du swap supprime la table de swap statique et réduit de 30%, selon les chiffres publiés, les métadonnées conservées par le noyau pour votre périphérique de swap. MGLRU peut vérifier les indicateurs young des pages par lots, avec le gain publié le plus important sur un serveur Arm doté de nombreux cœurs. Et clone3() a gagné CLONE_AUTOREAP, CLONE_NNP et CLONE_PIDFD_AUTOKILL, ce qui rend la supervision des processus enfants plus sûre. Les informations de protection T10 au niveau du système de fichiers ont également été ajoutées, mais un disque virtuel expose rarement les métadonnées d’intégrité nécessaires.

La mise à niveau de mon noyau peut-elle casser mon VPS ?

Les échecs courants se produisent au démarrage. Un /boot complet fait échouer update-initramfs avec No space left on device pendant l’installation et laisse le paquet à moitié configuré : supprimez les anciens noyaux avec sudo apt autoremove --purge, puis réinstallez. Les modules externes construits pour l’ancien noyau cessent de se charger. Tout ce qui est géré par DKMS doit donc être recompilé. Un échec de recompilation reste silencieux jusqu’à ce que le module manque au moment de l’exécution. Enfin, si uname -r indique toujours l’ancienne version après un redémarrage alors que dpkg -l liste la nouvelle image, l’installation n’a pas échoué : la valeur par défaut du bootloader n’a pas changé.