La demande d'intégration réseau de Linux 7.3 est arrivée le jeudi vingt août, et le chiffre important ne figure pas dans le diffstat. Jakub Kicinski et Paolo Abeni ont fusionné 632 correctifs par net et 648 par net-next, et Kicinski estime qu'un tiers à une moitié du côté net-next ressemble à des correctifs de faible priorité produits par des IA, des nettoyages et des clarifications. Son résumé tient en quatre mots : nous sommes totalement submergés. La réponse est la partie intéressante. Plutôt que de fermer la porte aux correctifs écrits par des machines, netdev a obtenu un budget LLM auprès de Meta et fait relire chaque correctif par plusieurs modèles de pointe avant qu'un humain ne s'y penche.
The short answer
La fenêtre de fusion réseau de Linux 7.3 s'est refermée le jeudi vingt août 2026. Jakub Kicinski et Paolo Abeni ont fusionné 632 correctifs net et 648 correctifs net-next, et Kicinski décrit les mainteneurs comme totalement submergés par les contributions générées par IA. Netdev ne les interdit pas. Le sous-système a obtenu un budget et un accès LLM auprès de Meta, fait relire chaque correctif par plusieurs modèles de pointe pour écarter les hallucinations, et prévoit de confier le travail de procédure aux modèles au prochain cycle.
La plupart des demandes d'intégration du noyau vous disent ce qui a été ajouté. Celle-ci vous dit ce qu'il a fallu payer pour l'accepter, ce qui est plus rare et nettement plus utile si vous maintenez quoi que ce soit auquel des inconnus envoient des correctifs.
Le chiffre derrière le chiffre
Kicinski ouvre sur ce qu'il appelle un comptage rapide et approximatif : un nombre très proche de correctifs passés par net (632) et par net-next (648). Répartis entre deux mainteneurs sur une fenêtre de fusion, cela ressemble à un trimestre normal pour le plus gros sous-système du noyau.
Puis vient la précision qui rend le tout anormal. Un tiers à une moitié des correctifs net-next, selon sa lecture, ressemblent à des correctifs de faible priorité produits par des IA, à des nettoyages et à des clarifications. Rien de faux. Rien de malveillant. Simplement du travail que personne n'a demandé, arrivant plus vite que ne peuvent lire les personnes qui en répondent.
Son résumé tient en quatre mots : nous sommes totalement submergés.
Cette phrase pèse lourd par l'endroit d'où elle vient. Netdev est l'un des sous-systèmes les mieux dotés de l'arbre, avec des mainteneurs à temps plein payés par des entreprises dont l'activité dépend de la correction de ce code. Si le circuit de relecture craque là, ce n'est pas le genre de problème qu'un peu plus de financement résout.
Pourquoi dire non ne règle rien ici
Deux autres projets ont tranché dans l'autre sens ce mois-ci. Greg Kroah-Hartman a fermé drivers/staging aux correctifs écrits par LLM parce que staging existe pour former des humains, et que les nettoyages faciles sont le programme pédagogique. Le comité de pilotage de GCC a refusé les contributions juridiquement significatives dérivées de LLM pour des raisons de droit d'auteur. Debian vote sur huit options de bulletin pour la même question.
Netdev ne peut emprunter proprement aucune de ces sorties. Un correctif d'une ligne sur un chemin d'erreur de pilote n'est pas juridiquement significatif, il n'apprend rien à personne, et s'il est correct, le refuser revient à livrer un défaut connu par principe. Le sous-système a déjà tenté de réduire la surface, en supprimant du vieux code réseau et des pilotes que plus personne n'utilise sur un noyau récent, précisément pour couper le bruit qui arrivait dessus. Les correctifs ont continué d'affluer.
Reste donc à rendre la relecture moins coûteuse par correctif plutôt qu'à rendre les correctifs plus rares.
Plusieurs modèles, un correctif
Le mécanisme décrit par Kicinski est simple. Netdev a obtenu un budget et un accès LLM suffisants, avec un remerciement à Meta, pour faire tourner des relectures avec plusieurs modèles de pointe sur chaque correctif. Faire passer plusieurs modèles indépendants sur le même diff et comparer ce qu'ils signalent est une façon raisonnable de filtrer les trouvailles hallucinées, parce qu'un défaut qu'un seul modèle voit est en général un défaut qui n'existe pas.
Il reste prudent sur les limites : en matière de relecture, les LLM ne peuvent faire qu'une partie du chemin.
L'aveu qui suit est plus intéressant. Les API de netdev, écrit-il, en particulier pour les évènements rares comme les erreurs PCIe et les délais d'attente, ont toujours comporté des courses critiques, et les LLM ne laissent plus les mainteneurs les ignorer. Des modèles qui lisent l'arbre entier à grande échelle font remonter chaque course théorique qu'un relecteur humain avait appris à ignorer. Prises une par une, ces remontées sont souvent défendables. Prises ensemble, elles constituent un déni d'attention, car le coût de décider qu'une course est inatteignable en pratique est presque le même que celui d'en corriger une qui ne l'est pas.
Ce qui change au prochain cycle
La direction esquissée par Kicinski est un glissement : des modèles pour relire le code vers des modèles pour faire tourner la procédure.
- gérer patchwork, le système de suivi où les correctifs netdev attendent leur tour
- automatiser les remarques de procédure que les mainteneurs tapent aujourd'hui à la main
- rédiger les messages de commit
- éventuellement appliquer les correctifs portant déjà une étiquette reviewed-by d'une personne à qui les mainteneurs font confiance
Relisez le dernier point lentement. Il place une machine sur le chemin d'intégration de changements qu'un humain de confiance a déjà validés, ce qui est plus étroit qu'il n'y paraît mais reste un seuil que le noyau n'avait pas franchi.
Les fonctionnalités, puisqu'elles ont bien été livrées
Le cœur de la pile gagne le support de BIG TCP à l'intérieur des tunnels UDP via les pilotes VXLAN et Geneve, ce qui compte si vous exploitez des réseaux superposés et laissiez des gains de déchargement de côté à la frontière du tunnel. MPTCP gère mieux les fortes pressions mémoire.
Côté pilotes filaires, on trouve un support CXL initial pour les cartes AMD et Solarflare, le flashage de micrologiciel pour les cartes AMD Pensando, et le premier squelette du pilote Intel iXD. Ce dernier existe pour prendre en charge la Control Plane PIC Function des IPU et FNIC Intel E2100 et ultérieurs, et pour 7.3 il ne s'agit que d'infrastructure : il n'y a donc rien à tester tant que vous n'avez pas le matériel et un goût pour le travail de pilote très amont.
Le sans-fil récupère la suite du travail Multi Link Operation, le nouveau pilote mm81x pour les équipements longue portée S1G de Morse Micro, NXPWIFI pour le matériel NXP, et le support MT7928 et MT7925 NAN dans MT76.
Ce que nous en retenons
Si vous maintenez quoi que ce soit de public, l'expérience de netdev est un avant-goût plutôt qu'une curiosité. Le mode de défaillance n'est pas le mauvais correctif, c'est le correctif défendable à un rythme qui dépasse la relecture humaine, et les interdictions de principe ne fonctionnent que là où l'on peut justifier de refuser du code correct.
La leçon pratique se trouve dans la remarque sur les courses critiques. Netdev n'est pas puni pour de la négligence. Le sous-système est audité par des lecteurs infatigables, sur des interfaces conçues à une époque où personne ne pouvait se permettre de tout lire. Toute base de code qui garde des hypothèses tacites dans ses chemins d'erreur se trouve dans la même situation, et l'audit tourne déjà, que les signalements vous soient parvenus ou non.
Sources et pour aller plus loin
- Linux 7.3 Network Changes Merged But Developers Completely Overwhelmed Due To AI/LLMs, Phoronix, 20 août 2026
- Fil de discussion sur la demande d'intégration réseau de Linux 7.3, Linux.org
- Kicinski: netdev in 2023, LWN.net
Questions fréquentes
Combien de correctifs sont réellement entrés dans le réseau de Linux 7.3 ?
Kicinski donne un comptage rapide et approximatif : 632 correctifs fusionnés par net, l'arbre des corrections, et 648 par net-next, l'arbre des fonctionnalités, soit 1 280 sur le cycle. Il partage ce travail avec Paolo Abeni. Le chiffre brut n'a rien d'extraordinaire pour le réseau, qui reste l'un des plus gros sous-systèmes du noyau. Ce qui est nouveau, c'est la composition : il estime qu'un tiers à une moitié des correctifs net-next ressemblent à des correctifs de faible priorité produits par des IA plutôt qu'à du travail dont quelqu'un avait besoin pour une machine qu'il possède.
Netdev rejette-t-il les correctifs générés par LLM comme d autres sous-systèmes ?
Non, et c'est précisément la ligne de partage. L'arbre staging et GCC ont tous deux choisi la voie réglementaire et refusé les contributions écrites par des machines. Netdev a fait l'inverse. Le sous-système ne peut pas refuser des correctifs individuellement corrects, alors il a industrialisé la relecture : plusieurs modèles de pointe examinent chaque correctif en amont, ce qui, selon Kicinski, élimine une partie des hallucinations avant qu'un mainteneur n'y consacre son attention. Le plan du prochain cycle va plus loin en confiant aussi le travail de procédure aux modèles.
Que vient faire Meta dans la relecture du réseau du noyau ?
Kicinski remercie Meta pour le budget et l'accès LLM qui rendent possible la relecture multi-modèles, et il y travaille. Faire passer plusieurs modèles de pointe sur plus de mille correctifs par cycle représente une facture d'inférence réelle, et les mainteneurs n'ont aucun moyen de la payer eux-mêmes. Il faut nommer clairement cet arrangement : un sponsor industriel finance désormais la capacité de relecture qui fait avancer un sous-système central du noyau, ce qui constitue une dépendance d'un nouveau genre, même si les décisions de relecture restent aux mains des mainteneurs.
Que signifie la remarque sur les API sujettes aux courses critiques ?
Kicinski écrit que la triste vérité est que les API de netdev, en particulier autour des évènements rares comme les erreurs PCIe et les délais d'attente, ont toujours comporté des courses critiques, et que les LLM ne permettent plus de les ignorer. Des modèles qui lisent l'arbre entier à grande échelle exhument toutes les courses théoriques que les relecteurs humains avaient appris à contourner. La plupart de ces signalements sont valides et sans portée pratique, et c'est exactement ce qui les rend coûteux. Il faut toujours lire chacun d'eux pour décider de quelle catégorie il relève.
Quelles fonctionnalités réseau ont réellement été livrées ?
BIG TCP fonctionne désormais dans les tunnels UDP via les pilotes VXLAN et Geneve, MPTCP gère mieux les fortes pressions mémoire, et le cœur de la pile a reçu d'autres améliorations. Côté pilotes, on trouve un support CXL initial pour les cartes AMD et Solarflare, le flashage de micrologiciel pour les cartes AMD Pensando, et un pilote Intel iXD squelettique pour la Control Plane PIC Function des IPU E2100 et ultérieurs. Le sans-fil gagne la poursuite du travail Multi Link Operation, un pilote mm81x pour les équipements longue portée S1G de Morse Micro, un nouveau pilote NXPWIFI, et le support MT7928 et MT7925 NAN dans MT76.