NetworkNews

Linux 7.2-rc5 est gros, et un tiers vient du réseau

Sur cette page
  1. Ce que Torvalds a réellement dit
  2. Où sont vraiment les changements
  3. Tester celle ci, si vous vous y mettez
  4. Ce qu'il faut surveiller ensuite
  5. Sources et pour aller plus loin

Linux 7.2-rc5 est sorti le dimanche vingt six juillet, et plus d'un tiers de son contenu concerne le réseau, presque entièrement côté pilotes plutôt que dans la pile elle même. Linus Torvalds l'a qualifié de rc5 franchement massif tout en précisant, dans la même phrase, que rien ne lui semblait particulièrement étrange ni inquiétant. Les deux moitiés de cette phrase comptent si vous décidez quoi tester. Une release candidate de fin de cycle aussi volumineuse est inhabituelle, l'explication avancée est banale, et la forme du diff vous dit exactement quelles machines méritent d'être mises sous charge avant la sortie stable du seize août.

The short answer

Linux 7.2-rc5 est arrivé le vingt six juillet, exceptionnellement volumineux pour une release candidate de fin de cycle. Plus de trente cinq pour cent des changements touchent le réseau, presque uniquement côté pilotes, ce que Torvalds impute à un retard qui se résorbe après une semaine de conférences. Les changements USB dépassent ceux des GPU, une inversion inhabituelle à ce stade. Son verdict : un peu trop gros à son goût, mais rien d'étrange ni d'inquiétant. Stable visée le seize août.

>35%des changements concernent le réseau, surtout les pilotes
26 juilletdate de publication de rc5 sur kernel.org
16 aoûtdate visée pour la sortie stable de 7.2
Carte réponse : Linux 7.2-rc5 est sorti le 26 juillet 2026 avec plus de 35 pour cent de ses changements dans le sous système réseau, surtout des pilotes, ce que Torvalds attribue à un retard accumulé pendant une semaine de conférences, la version stable 7.2 étant attendue le 16 août 2026.
Une grosse rc5, et une rc5 ennuyeuse, ce qui est le bon résultat. Source : annonce de 7.2-rc5, vingt six juillet. PNG

Les release candidates sont censées rétrécir à mesure que le cycle s'achève. C'est tout l'intérêt de la forme : la fenêtre de fusion absorbe les nouveautés, et les sept semaines qui suivent forment une série décroissante de correctifs jusqu'à ce que la courbe s'aplatisse et que Torvalds étiquette un noyau stable. Alors quand une rc5 arrive visiblement plus grosse qu'une rc5 ne l'est d'habitude, la question intéressante n'est pas de savoir si c'est mauvais. C'est de savoir pourquoi.

Ce que Torvalds a réellement dit

L'annonce contient à la fois la plainte et le rassurement. Il parle d'une rc5 franchement massive, puis : un peu trop grosse à mon goût, mais rien ne me paraît particulièrement étrange ou inquiétant.

Lire les deux ensemble, c'est tout le savoir faire. La taille et le risque sont deux axes distincts, et les confondre conduit soit à ignorer un petit correctif réellement dangereux, soit à paniquer devant un gros correctif inoffensif. Un diff de cinq mille lignes qui corrige des particularités sur deux cents cartes réseau précises n'a pas du tout le même profil de risque qu'un changement de deux cents lignes dans la gestion mémoire. Le premier ne concerne que les possesseurs de ce matériel et échoue de façon visible. Le second peut toucher tout le monde et échouer discrètement.

Son explication du volume est tout aussi peu spectaculaire. Les mainteneurs étaient en conférence la semaine précédente, donc des demandes de fusion normalement réparties sur deux semaines sont arrivées tassées sur une. C'est un artefact de calendrier, pas un signal sur la qualité du code. Il a par ailleurs décrit les noyaux plus volumineux comme la nouvelle normalité, ce qui vaut d'être noté en arrière plan : la ligne de base monte indépendamment de telle ou telle semaine.

Où sont vraiment les changements

Le réseau prend plus de trente cinq pour cent du total, et la nuance importante est qu'il s'agit surtout de pilotes et non du cœur des protocoles. Les modifications de la pile réseau elle même, celles qui décident comment les paquets sont mis en file, gérés en congestion et routés, sont celles qui peuvent affecter toutes les machines. Les modifications du pilote d'une carte donnée n'affectent exactement que ceux qui exploitent cette carte.

Le second détail est une vraie curiosité : les changements USB dépassent cette fois ceux des GPU. Les pilotes graphiques sont normalement le premier contributeur au brassage de code du noyau en pur volume, donc une inversion aussi tardive dans un cycle mérite d'être signalée.

Au delà de ces deux là, la version se répartit sur le son, le TTY, le bloc, firewire, les systèmes de fichiers dont SMB et btrfs, les liaisons Rust, des correctifs propres à certaines architectures, l'outillage dans selftests et perf, et la documentation. On y trouve aussi une jolie pièce d'archéologie noyau : un bug de réseau IPv4 sur firewire qui traînait apparemment depuis environ 2009 a enfin été corrigé. Côté matériel, on note des gains de performance graphique sur Intel Panther Lake Xe3 et un réglage du stockage PCIe 5.0 sur AMD EPYC Turin.

Session terminal montrant comment récupérer et compiler une release candidate du noyau Linux : clonage de l'arbre git mainline, bascule sur l'étiquette v7.2-rc5, copie de la configuration du noyau en cours avec cp /boot/config-$(uname -r) .config, exécution de make olddefconfig, compilation avec make -j$(nproc), puis installation des modules et du noyau avant de redémarrer dessus.
La façon standard de poser une release candidate sur une machine de test. Jamais en production. PNG

Tester celle ci, si vous vous y mettez

L'utilité dépend entièrement de ce que vous exploitez. L'intérêt de tester une release candidate, c'est que les régressions sont trouvées sur votre matériel avant d'atteindre un noyau stable qui finira dans une distribution que vous déployez vraiment. Cet intérêt est réel, mais il n'existe que si la machine de test ressemble à la machine de production sur les points qui comptent.

Pour cette rc en particulier, cela veut dire les cartes réseau. Plus d'un tiers des changements sont là, donc si vous exploitez autre chose que la puce grand public la plus répandue au monde, vous faites partie de la population capable de trouver ce que personne d'autre ne trouvera. L'agrégation, les VLAN, les réglages de déchargement et tout ce qui pousse le pilote sur ses chemins les moins fréquentés sont les endroits où les régressions apparaissent, et aucun d'eux ne se révèle en charge légère.

L'USB mérite aussi un coup d'œil, vu qu'il pèse plus que le graphique ce cycle ci. Si vous avez des adaptateurs série, des cartes d'acquisition ou n'importe quel périphérique USB dont dépend un service, éprouvez le plutôt que de le supposer intact.

La mécanique n'a rien changé et rien de remarquable. Récupérez l'arbre mainline, basculez sur l'étiquette v7.2-rc5, partez de votre configuration en cours avec une copie du config présent dans /boot suivie d'un make olddefconfig pour que les nouveaux symboles prennent des valeurs raisonnables, compilez, installez les modules et le noyau, puis démarrez dessus. Gardez le noyau précédent dans le chargeur d'amorçage, ce que toute distribution sensée fait par défaut, pour qu'un démarrage raté vous coûte un redémarrage et non une séance de récupération.

La seule règle qui ne se négocie pas concerne l'endroit. Les release candidates vont sur des machines de préproduction et du matériel de rechange, pas sur ce qui porte du trafic important. Ce n'est pas de la prudence gratuite, c'est ce qui rend le test de rc utile : tout le système repose sur le fait que les problèmes soient découverts là où un plantage n'est qu'agaçant.

Ce qu'il faut surveiller ensuite

Le calendrier vise le seize août pour la 7.2 stable, ce qui laisse rc6 et rc7 à environ une semaine d'intervalle. Le signal à surveiller est de savoir si rc6 arrive nettement plus petite. Si l'explication du retard de conférence est la bonne, cela devrait être le cas, parce qu'une compression ponctuelle des demandes de fusion ne se répète pas. Si rc6 arrive volumineuse elle aussi, l'histoire du retard paraît moins complète et une release candidate supplémentaire devient plus probable, Torvalds prolongeant volontiers un cycle quand quelque chose de tardif semble mal stabilisé.

Pour la plupart des gens, la réponse pratique est d'attendre l'étiquette stable et de laisser la distribution faire le travail d'intégration. Pour qui exploite du matériel réseau inhabituel, les trois prochaines semaines sont la fenêtre où trouver un problème coûte encore peu.

Sources et pour aller plus loin

Questions fréquentes

Un rc5 surdimensionné doit-il inquiéter pour la 7.2 ?

Pas en soi. La taille et le risque sont deux mesures différentes, et Torvalds a traité les deux explicitement : trop gros à son goût, mais rien qui lui paraisse étrange ou inquiétant. La distinction est réelle, car un gros diff composé de correctifs de pilotes pour du matériel précis est bien moins dangereux qu'un petit diff qui touche l'ordonnanceur ou la gestion mémoire. Celui ci est dominé par les pilotes. Ce qu'un rc5 volumineux implique vraiment, c'est qu'il reste moins de cycle pour faire remonter ce qui a glissé dedans : une raison de tester tôt, pas de sauter la version.

Pourquoi autant de code réseau si tard dans le cycle ?

Torvalds l'attribue à un retard accumulé, pas à un problème structurel. Les mainteneurs étaient en conférence la semaine précédente, donc les demandes de fusion qui seraient normalement arrivées étalées sur deux semaines sont tombées comprimées sur une seule. C'est un artefact de calendrier propre au fonctionnement réel du développement noyau, pas un signe que le réseau va mal. Il a par ailleurs décrit les versions plus volumineuses comme la nouvelle normalité, donc la ligne de base monte depuis un moment.

Quels sous systèmes faut-il réellement tester ?

Commencez par les pilotes réseau, puisque c'est là que se trouvent plus de trente cinq pour cent des changements, et précisément les cartes que vous exploitez en production plutôt que celles que vous possédez. Ensuite, l'USB mérite un passage car les changements USB dépassent cette fois ceux des GPU, une inversion inhabituelle en fin de cycle. Le son, le TTY, le bloc, firewire, SMB, btrfs, les liaisons Rust, perf et les selftests ont aussi reçu du travail : si vous en dépendez, c'est la rc à éprouver.

Quand la 7.2 stable arrive-t-elle vraiment ?

Le seize août 2026 selon le calendrier actuel, soit un peu moins de trois semaines après rc5. Cela suppose un cycle de longueur habituelle avec rc6 et rc7 à intervalle hebdomadaire. Torvalds prolonge parfois d'une release candidate supplémentaire quand quelque chose de tardif semble non résolu : considérez cette date comme le plan plutôt que comme une garantie, et regardez si rc6 arrive nettement plus petite.

Peut-on faire tourner une rc sur une machine importante ?

Non, et cela n'a pas changé. Les release candidates existent pour que les problèmes apparaissent sur des machines où un redémarrage ne coûte rien. La bonne pratique est une machine de préproduction ou une machine de rechange dont le matériel correspond vraiment à la production, car une régression de pilote ne se manifeste que sur le silicium concerné. Tester 7.2-rc5 sur un portable ne vous apprend presque rien sur la carte réseau de votre baie.

Advertisement