Noyau Linux 7.1 : quelles nouveautés pour les serveurs ?

Les 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 cette version concerne principalement le bureau et les graphiques, que les serveurs sans interface graphique ne chargent jamais.

Il faut d’abord apporter une deuxième réponse. La version 7.1 n’est presque certainement pas exécutée sur votre serveur et ne le sera pas avant longtemps. kernel.org ne répertorie pas la version 7.1 comme une version longterm. Au 11 août 2026, les branches longterm sont 6.18, 6.12, 6.6, 6.1, 5.15 et 5.10, et chaque distribution serveur courante s’appuie sur l’une d’elles ou sur une branche qu’elle maintient elle-même. Les nouveautés du noyau et celles qui sont nouvelles sur votre serveur apparaissent à plusieurs années d’intervalle. Ce guide couvre donc les deux aspects.

Quel kernel votre VPS utilise-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 avant le premier tiret correspond à la branche upstream. Tout ce qui suit est le numéro de build propre à votre distribution, qui ne suit pas du tout l’upstream. Le 6.8.0-79 de Canonical intègre 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 indique si vous pouvez modifier le kernel. La commande affiche kvm sur une machine virtuelle complète, dans laquelle vous démarrez votre propre image de kernel et où une mise à niveau constitue une véritable mise à niveau. Elle affiche lxc ou openvz sur une virtualisation par conteneurs, dans laquelle le kernel de l’hôte est partagé. Sur une offre de conteneur, uname -r affiche le kernel du fournisseur. Installer un paquet 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 prise en charge 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. Le décompte des releases est une mesure approximative, car il ne tient pas compte de tout ce que les distributions rétroportent. Il montre néanmoins l’ampleur de l’écart. Si vous évaluez laquelle de ces distributions utiliser, l’arbitrage 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, au lieu de limiter cette opération à la couche bloc. Cette version ajoute aussi 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 dirigé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, la contrainte vient du matériel. 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 bloc ne crée le répertoire integrity que lorsque le périphérique déclare prendre en charge 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’examiner plus en détail les fonctions de stockage, commencez par vérifier si le disque VPS est réellement un périphérique NVMe. La différence entre NVMe et un SSD SATA sur un VPS explique pourquoi le résultat modifie vos chiffres.

Btrfs corrige l’amplification liée au copy-on-write sous pression mémoire. Une autre modification accélère l’effacement de la première extent dans une plage suivie. Le changement a produit un débit supérieur de 10 % sur la charge de travail de référence indiquée dans le commit de fusion. 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 temps réel, ce qui prépare la prise en charge des périphériques zonés. NTFS fait l’objet d’une réécriture complète dans cette version. Il prend désormais entièrement en charge l’écriture et utilise iomap. Cela est utile si vous montez sur votre serveur une image disque provenant d’une machine Windows.

Quelques autres changements de stockage méritent d’être connus : ublk, le pilote bloc en espace utilisateur, prend désormais en charge les entrées-sorties 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 intégré au noyau 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 possibilités pour un conteneur

La principale évolution du 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 jouer le rôle 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 remet les paquets bruts à l’espace utilisateur sans les copier à travers la pile réseau) devait recevoir une partie presque complète du périphérique. Avec une file louée, il obtient une file matérielle, exécute AF_XDP et les fournisseurs de mémoire à vitesse native, tandis que l’hôte conserve le reste de la NIC. Cette évolution s’ajoute à la prise en charge d’AF_XDP dans le chemin zero-copy d’io_uring.

Du côté plus 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 xattrs du système de fichiers sous-jacent, mais un socket présent uniquement dans sockfs n’en avait aucune. Un processus peut maintenant étiqueter un socket, et un programme eBPF peut filtrer selon cette étiquette.

Deux suppressions sont à signaler. UDP-Lite disparaît, faute d’utilisateurs. IPv6 ne peut plus être compilé comme module chargeable : si vous voulez IPv6, il est compilé dans le noyau. Cette deuxième modification est invisible dans les noyaux des distributions, car les distributions serveur courantes compilent déjà IPv6 dans le noyau.

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

La refonte du swap entre dans sa troisième phase. Cette phase supprime la map statique du swap. Le nombre d’entrées de swap est désormais stocké directement dans la table de swap. L’économie annoncée représente environ 30 % des métadonnées statiques du swap. Il s’agit d’une mémoire que le kernel conserve en fonction de la taille de votre périphérique de swap, que des pages soient échangées ou non. En valeur absolue, cette économie reste faible avec un petit fichier de swap. Elle augmente avec la quantité de 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 sur les pages par lots, au lieu de traiter une page à la fois. Les chiffres publiés avec cette modification indiquent une amélioration de plus de 60 % sur un serveur Arm64 à 32 cores. Le traitement par lots est surtout avantageux lorsque le coût par page est élevé. C’est pourquoi cette valeur a été mesurée sur une grosse machine Arm. Si vous utilisez un VPS Arm plutôt qu’un VPS x86, c’est la modification de 7.1 qui a le plus de chances d’apparaître dans vos propres mesures, même si vous n’atteindrez pas cette échelle avec deux ou quatre cores.

Sont également concernés les transferts depuis les memory cgroups en cours de suppression, les scans de khugepaged, qui consomment moins de CPU, et le maple tree, qui a fait l’objet d’une importante refactorisation autour de la gestion de ses gros nœuds. Rien de tout cela ne se configure. Vous le remarquerez surtout par une légère diminution du temps système.

Planificateurs : sous-planificateurs sched_ext et FRED activé par défaut

sched_ext, la classe de planificateur extensible qui permet d’écrire un planificateur CPU sous forme de programme BPF et de le charger à chaud, est apparue dans la version 6.12. La version 7.1 ajoute la structure de base des sous-planificateurs, afin qu’un groupe de contrôle puisse à terme fonctionner avec son propre planificateur. 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 manquant. Il s’agit donc des fondations d’une version ultérieure, et non d’une fonctionnalité 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 remise des événements x86 par une implémentation plus propre. Il est présent dans le noyau depuis la version 6.9, derrière l’argument de démarrage 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% sur des charges fortement sollicitées par les E/S, proviennent de tests Phoronix effectués sur des processeurs clients. Ne prévoyez donc pas ces gains sur un serveur avant d’avoir mesuré votre propre charge.

L’exécution par proxy 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 minuteurs haute résolution a également été largement réécrit. Il s’agit d’améliorations de la qualité de la latence qu’aucun fichier de configuration ne permet d’exposer.

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

Trois indicateurs ont été ajoutés à clone3(). Chacun comble une lacune que les superviseurs contournaient manuellement depuis des années. CLONE_AUTOREAP fait en sorte que le processus enfant se réappareille lui-même à sa sortie. Il ne devient donc jamais un zombie qui attend un parent susceptible de 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 espaces de noms de montage bénéficient du même traitement. CLONE_EMPTY_MNTNS pour clone3() et UNSHARE_EMPTY_MNTNS pour unshare() créent un espace de noms de montage vide, au lieu de la copie complète habituelle des montages du parent qu’un runtime doit ensuite démonter. FSMOUNT_NAMESPACE permet à fsmount() de placer directement un système de fichiers dans un nouvel espace de noms. Les runtimes de conteneurs construisent cette configuration manuellement depuis dix ans. La réaliser en un seul appel signifie qu’un runtime ne démarre plus avec un espace de noms 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 défauts de page du système invité depuis l’espace utilisateur. KVM protégé sur Arm prend désormais en charge la mémoire anonyme. Le commit précise toutefois que cette fonctionnalité n’est pas prête pour la production.

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

Fedora l’utilise 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 réaligne son kernel sur les nouvelles versions stables pendant le cycle d’une version. Arch et openSUSE Tumbleweed l’utilisent pour la même raison. Ces systèmes servent à effectuer des tests, pas à exécuter vos services.

Tous les autres attendent, et cette attente est volontaire. Debian 13 est fourni avec le kernel 6.12 et reste sur 6.12 pendant toute la durée de vie de cette version, avec les correctifs rétroportés. RHEL 10 est fourni avec 6.12.0 et suit le même modèle. Ubuntu 26.04 LTS est sorti avec le kernel 7.0 en avril 2026. Ubuntu 24.04 LTS dispose d’une HWE stack, qui récupère un kernel plus récent dans les versions ultérieures d’Ubuntu pour l’intégrer à la LTS. Cette stack est en 6.17 depuis la point release 24.04.4 et doit passer en 7.0 avec la version 24.04.5, prévue le 27 août 2026. Une point release n’est pas une nouvelle version d’Ubuntu. Il s’agit toujours de 24.04, avec toutes les mises à jour publiées depuis intégrées aux supports d’installation. Ainsi, les changements apportés par 24.04.5 à un serveur que vous mettez déjà à jour concernent surtout la ligne de kernel HWE, et très peu d’autres éléments.

C’est ici que les erreurs sont fréquentes. Une HWE stack adopte le kernel fourni par la dernière version intermédiaire. Elle peut donc ignorer complètement une ligne upstream. Le kernel 7.0 est inclus dans une Ubuntu LTS. Le 7.1 ne sera peut-être jamais la base d’une LTS, car la version intermédiaire suivante utilisera une ligne plus récente. Ce qui arrive de 7.1 dans votre LTS, ce sont les correctifs, rétroportés dans la ligne que vous utilisez. Les fonctionnalités restent pour l’essentiel dans la version upstream.

Si vous souhaitez tout de même utiliser un kernel 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 kernel effectivement démarré :

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

uname -r doit maintenant afficher la nouvelle ligne, tandis que dpkg -l affiche toutes les images de kernel encore installées. Si uname -r affiche l’ancienne version alors que dpkg -l répertorie la nouvelle, le package est installé, mais l’entrée 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 package a mis à jour le kernel 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 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 version stable et les testent avec l’espace utilisateur fourni avec celle-ci. Un kernel mainline provenant d’une archive tierce ou compilé manuellement vous apporte les 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 peut pas piloter, ou une modification des performances que vous avez mesurée sur votre propre charge de travail et que vous êtes prêt à utiliser malgré les conséquences. Sur un VPS, le premier cas ne s’applique presque jamais, car le matériel auquel vous avez accès est virtualisé. 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à sur votre liste, passer d’Ubuntu 24.04 à 26.04 vous fait passer de 6.8 à 7.0 en une seule étape, soit un saut plus important que celui fourni par n’importe quel paquet de kernel.

FAQ

Comment vérifier la version du noyau Linux utilisée par mon VPS ?

Exécutez uname -r. La commande affiche une valeur semblable à 6.8.0-79-generic. Le numéro situé avant le premier tiret correspond à la branche amont sur laquelle votre distribution est basée. Tout ce qui suit correspond au numéro de build propre à la distribution, qui intègre des correctifs rétroporté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 vous devez gérer vous-même ses mises à niveau.

Linux 7.1 est-il un noyau bénéficiant d’un support à long terme ?

Non. Au 11 août 2026, les branches longterm listé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 normale. 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 est fourni avec la version 7.0. Une stack Ubuntu hardware enablement passe à la version du noyau utilisée par la dernière release interim. Elle peut donc ignorer entièrement une branche amont. Ubuntu 24.04 LTS doit faire passer son noyau HWE en 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. Ce ne sera généralement pas le cas des fonctionnalités.

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

Quatre éléments. Le partage de files d’attente matérielles permet à un conteneur d’utiliser une file 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 sécurise la supervision des processus fils. 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 risque-t-elle de casser mon VPS ?

Les pannes courantes surviennent 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 compilés pour l’ancien noyau cessent de se charger. Tout ce qui est géré par DKMS doit donc être recompilé. Un échec de cette recompilation peut rester silencieux jusqu’à ce que le module manque au moment de l’exécution. Enfin, si uname -r affiche toujours l’ancienne version après un redémarrage alors que dpkg -l liste la nouvelle image, l’installation n’a pas échoué : la version par défaut du bootloader n’a pas changé.