Sortie du noyau Linux 4.11

La sortie de la version stable 4.11 du noyau Linux a été annoncée le 1^er mai 2017 par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site kernel.org.

Sommaire

• Annonces des versions candidates par Linus Torvalds
  • RC-1
  • RC-2
  • RC-3
  • RC-4
  • RC-5
  • RC-6
  • RC-7
  • RC-8
  • Version finale
• Améliorations apportées à cette version
  • Processeurs
    • Intel
  • Architectures
    • x86
    • Allwinner
    • Samsung
    • Qualcomm
  • Protocoles
    • Samba
• Matériel
• syscall
• Réseau
  • ICMP
  • Divers
  • Sécurité
• Statistiques

Annonces des versions candidates par Linus Torvalds

RC-1

La version RC-1 est sortie le 5 mars 2017 :

Deux semaines sont passées, la fenêtre de fusion s’est terminée et 4.11-rc1 a été étiquetée et publiée.

Cela ressemble à une version habituelle. Elle semble appartenir à une variété comportant peu de modifications, mais principalement comparée aux 4.9 et 4.10 — ce n’est pas à proprement parler singulièrement petit (dans les derniers noyaux, 4.1, 4.3, 4.5, 4.7 et maintenant 4.11, toutes avaient environ le même nombre de commits dans la fenêtre de fusion).

Il semble bien qu’il y avait plus de choses à intégrer que ce qui était dans linux-next. C’est toujours ce qu’il se passe, mais il semble que ce soit plus que d’ordinaire. Comparé à l’arborescence de linux-next au moment de la publication de la version 4.10, environ 18 % des commits hors fusion n’étaient pas dans linux-next. Cela semble plus élevé que d’habitude, bien que j’imagine que Stephen Rothwell doit avoir les vrais chiffres des fusions passées.

Maintenant, environ un quart des correctifs qui n’étaient pas dans linux-next finissent par avoir le même identifiant [ID patch] que quelque chose qui y était, donc une partie était due juste à du rebasing. Cependant, nous avons environ 13 % de la fenêtre de fusion qui n’était pas dans linux-next quand la 4.10 est sortie.

En en regardant les sources, il y a quelques classes différentes :

• des corrections :
  C’est évidemment bien et inévitable. Je ne m’attends pas à ce que tout ait été dans linux-next, après tout.

• les appels système de statx() :
  Ouais, je vais garder celui‐ci aussi parce que, franchement, la première version de ce correctif a été postée il y a plus de six ans.

• il y a l’assez remarquable série de scissions dans <linux/sched.h> :
  Celui‐ci a été posté et discuté avant la fenêtre de fusion, et a dû être fusionné en retard (et a même alors causé quelques conflits). Il y avait donc de vraies raisons pour la tardive inclusion.

• quelques sous‐systèmes ; DRM, InfiniBand, watchdog et Btrfs se démarquent :
  Ce dernier cas est ce que j’ai trouvé plutôt ennuyeux pour cette fenêtre de fusion.

En particulier, si vous ne pouvez pas suivre les simples règles de la fenêtre d’intégration (le processus entier de la fenêtre d’intégration et de linux-next est en place depuis plus d’une décennie), au moins faites en sorte que le résultat final ait bonne allure. Que tout ait l’air naturel et exempt de tout problème. Faites en sorte d’avoir l’air de savoir ce que vous faites, et assurez‐vous vraiment que le code a été exhaustivement testé d’une autre façon.

Parce que si vous contournez les contrôles sanitaires de linux-next, vous feriez mieux d’avoir vos propres contrôles sanitaires, avec lesquels vous les remplacerez. Ou alors, vous avez juste besoin d’être tellement bon que personne ne vous en voudra de les contourner, et personne ne remarquera jamais vos raccourcis.

Se dire « ignorons toutes les règles et les processus que nous avons mis en place pour vérifier les choses » et ensuite m’envoyer de la daube qui ne compile même pas, pour moi ce n’est pas acceptable.

Vous savez qui vous êtes. Pour la prochaine fenêtre de fusion je n’accepterai rien de tel, même à distance. Les choses qui n’ont pas été dans linux-next seront rejetées et, puisque vous êtes déjà sur ma liste noire, je vous crierai dessus une fois de plus.

Linus

RC-2

La version RC-2 est sortie le 12 mars 2017 :

Comme d’habitude, la semaine qui suit la RC-1 tend à être assez calme quand les gens cherchent toujours des bogues et reprennent leur souffle après la fenêtre d’intégration. Mais nous avons là un nombre assez sain de correctifs, et il y a des correctifs de nettoyage et de préparation pour la gestion des tables de pages à cinq niveaux que j’ai pris après la fenêtre d’intégration, juste pour faciliter cette phase d’intégration.

Il y a aussi une (petite) mise à jour tardive du pilote des nombres aléatoires.

Mais pour la plupart, il ne s’agit que de correctifs, la majeure partie concernant les architectures et les pilotes (PowerPC et i915, respectivement, se démarquent), mais avec un composant notable situé ailleurs (les correctifs mm principalement via Andrew, quelques mises à jour des systèmes de fichiers, mise à jour des tests des arbres radix, etc.).

Les détails sont ajoutés au journal abrégé. Allez‐y, testez. Je pense que nous sommes en bonne forme pour aborder cette étape du développement noyau. Ça ne devrait pas être particulièrement effrayant de se dire « je vais me lancer à l’aventure et tester un noyau RC-2 ». D’accord, on est toujours dans les premières RC, mais continuez quand même. Aidez‐nous à nous assurer qu’on fait les choses correctement.

Linus

RC-3

Une nouvelle semaine, une nouvelle RC :

Suivant notre schéma habituel après la fenêtre d’intégration, la RC-3 est plus grande que la RC-2, mais nous arrivons heureusement au point où les choses commencent à se réduire et à se calmer. Nous avons eu une faute de frappe de dernière minute dans la RC-2 qui a affecté ARM et PowerPC (le code préparatoire pour les tables de pages à cinq niveaux) et, heureusement, il n’y a plus de bogues honteux de ce genre dans la RC-3.

Dans l’ensemble, la RC-3 a l’air assez normale, avec deux tiers de mises à jour de pilotes (les dernières mises à jour du pilote SCSI qla2xxx arrivent en tête, mais les pilotes Ethernet pour Broadcom et Cavium ne sont pas très loin derrière ; et il y a des mises à jour pour les processeurs graphiques, md, cpufreq, les pilotes de la plate‐forme x86, etc.).

En dehors des pilotes, le reste est un mélange de mises à jour des architectures (PA-RISC, PowerPC, x86), des systèmes de fichiers (AFS, NFS et XFS) et du « divers » (principalement le tronc commun du noyau et des mises à jour réseau générales).

Journal abrégé ci‐joint pour ceux qui veulent avoir un aperçu des détails, mais nous, ce qu’on veut, ce sont des tests. S’il vous plaît.

Linus

RC-4

La RC-4 est sortie le 26 mars 2017 :

Alors, la semaine dernière, j’ai dit que j’espérais que la RC-3 était le moment où l’on commençait à réduire les RC en taille et, oui, la RC-4 est plus petite que la RC-3. D’un tout petit soupçon. Elle touche bien à quelques fichiers de plus, mais elle compte deux commits de moins et comprend globalement moins de lignes modifiées. Mais dans l’ensemble, les deux sont à peu près de taille identique.

Ce qui n’est pas si mal, en fait, si l’on considère que la RC-4 comporte à la fois une fusion du côté du réseau et des traditionnels pilotes de chez Greg, et quelques correctifs DRM — et ça, ce sont généralement de gros morceaux.

Donc, dans l’ensemble, ça a l’air bien. Il y a des changements un peu partout et, pour la plupart, dans les proportions habituelles. Du code du cœur du noyau apparaît dans diffstat un peu plus qu’à l’accoutumée. Nous avons un correctif des audits, un correctif de la hashmap BPF, mais globalement tout a l’air normal : principalement des pilotes, du réseau, des correctifs d’architectures et un peu de bruit sur les systèmes de fichiers. Le journal abrégé est joint, comme d’habitude, pour les gens qui veulent écumer les détails.

Allez‐y, testez.

Linus

RC-5

La version RC-5 est sortie le dimanche 2 avril 2017 :

OK, les choses commencent à se calmer pour de bon. Espérons que cela continue comme ça et que ce ne soit pas juste un coup de bol.

Les choses ont l’air assez normales, avec seulement moins de 60 % des changements situés dans les pilotes (EDAC, son, périphériques en mode bloc_, PCI, etc.) et environ 30 % dans les mises à jour des architectures (quelques correctifs divers dans ptrace et des choses dans le générateur de nombres aléatoires).

La seule chose quelque peu inhabituelle est la façon dont plus de la moitié des mises à jour des architectures concernent PA-RISC, mais il ne s’agit que d’une curiosité temporaire du correctif des routines de copie en espace utilisateur de PA-RISC, duquel en a résulté un correctif assez gros (dû au fait qu’elles étaient écrites en assembleur ordinaire plutôt qu’en un bazar bogué formé d’assembleur inline avec quelques lignes de C mélangées au milieu).

Le reste se compose de divers correctifs de systèmes de fichiers (NFS[d], Btrfs), ainsi que de quelques correctifs au cœur du noyau et dans la gestion de mémoire.

Journal abrégé ci‐joint pour ceux qui aiment écumer les détails. Il n’est pas gros, survolez‐le simplement de haut en bas.

Linus

RC-6

La version RC-6 est sortie le dimanche 9 avril 2017 :

Tout semble normal, donc voici la RC hebdomadaire habituelle.

Elle est un peu plus grosse que la RC-5, cela dit rien d’alarmant ni de particulièrement inquiétant. Touchons du bois. La seule chose légèrement inhabituelle est la répartition des correctifs, presque à parts égales entre les mises à jour des architectures, les pilotes, les systèmes de fichiers, le réseau et « divers ».

Mais les dernières RC sont suffisamment petites pour voir plus de variations de ce genre de statistiques qu’on en voit dans les publications plus grosses, donc cette « distribution pas tout à fait habituelle » correspond plutôt au bruit normal du développement dans son ensemble.

Allez‐y, récupérez‐la.

Linus

RC-7

La version RC-7 est sortie le dimanche 16 avril 2017 :

Vous connaissez le principe à présent. Nous sommes en fin de phase RC et il se peut que ce soit la dernière RC si rien de surprenant ne se produit.

Les choses ont été assez calmes la semaine passée (le début de la semaine a été particulièrement calme et, comme d’habitude, vendredi est arrivé…). Nous avons un certain nombre de retours en arrière concernant les choses qui ne marchaient pas ou qui ne valaient pas la peine d’être corrigées à ce stade. C’est normal aussi (les gens regarderont ça pour la prochaine version à la place).

Donc, ce n’est pas trop gros et les choses ont l’air tout à fait normales, avec deux tiers des changements portés aux pilotes, et le reste étant un mélange de mises à jour des architectures (ARM, x86, IA64 et PA-RISC), du réseau et des systèmes de fichiers (Btrfs, CIFS et OrangeFS). Avec une poignée d’autres choses (outils, fichiers d’en‐têtes et cœur du noyau).

Merci de tester.

Linus

RC-8

La version RC-8 est sortie lundi 24 avril 2017 :

Alors, au départ, j’avais simplement prévu de publier la version 4.11 finale aujourd’hui. Mais, alors que nous n’avons pas eu beaucoup de changements la semaine dernière, nous en avons connu deux très ennuyeux, donc je publie encore une version RC à la place. J’ai bien reçu des correctifs pour les problèmes qui sont apparus, j’aurais donc pu publier la 4.11 telle quelle, mais ça ne semble pas opportun.

Ce n’est pas comme si la laisser mûrir une semaine de plus allait faire du mal.

Le plus notable des problèmes est que nous avons dû marquer certaines fonctions de la gestion de l’énergie de NVM Express (NVMe) qui posaient apparemment problème sur certaines machines. On n’a pas encore totalement élucidé la cause de ces problèmes (qui n’était pas limitée à quelques implémentations matérielles de NVMe, mais également à des plates‐formes particulières), mais testons tout cela.

Et nous avons aussi plusieurs correctifs de kernel oops, même s’ils n’étaient là que dans des cas très spéciaux.

Donc, allez‐y, testez, les filles et les gars, et assurez‐vous que je puisse faire une publication finale le week‐end prochain. D’accord ?

Linus

Version finale

Alors après cette semaine de plus avec une version RC-8, les choses ont été assez calmes et je suis bien plus à l’aise pour publier une version 4.11 finale maintenant.

Nous avons toujours différents correctifs de plus petite taille la dernière semaine, mais rien qui me fasse faire « Hmm… ». Journal abrégé ci‐joint pour ceux qui veulent examiner les détails, mais c’est un mélange d’un peu tout, avec environ la moitié concernant les pilotes (le réseau domine, mais quelques petites corrections concernant le son, également), le reste étant constitué de mises à jour des architectures, de la gestion générique du réseau, et des correctifs des systèmes de fichiers (NFS[d]). Mais tout cela reste assez maigre, ce qui est ce que j’aime voir la dernière semaine d’un cycle de publication.

Et avec ça, la fenêtre d’intégration est bien sûr ouverte. J’ai déjà deux demandes d’intégration [pull requests] dans ma boîte de courriel, j’en attends beaucoup plus tout au long de la nuit.

Linus

Améliorations apportées à cette version

Processeurs

Intel

• prise en charge des processeurs Intel de génération Kaby Lake (2017) par l’outil perf [lien] ;
• meilleure prise en charge des systèmes monpuces Bay Trail et Cherry Trail, avec l’ajout de la gestion du flux audio pour le HDMI et des C-state.

Architectures

x86

Nettoyage de code et optimisation.

Allwinner

• le Allwinner V3s est maintenant pris en charge ;
• le Allwinner A33 prend en charge cpufreq et des codecs audio ;
• le Allwinner A64 prend en charge le MMC et de l’USB.

Samsung

Arrivée de la gestion de l’USB 3.0 pour l’Exynos 5433.

Qualcomm

Meilleure prise en charge des diverses fonctions du système monopuce Snapdragon 410 (MSM8916).

Protocoles

Samba

Ajout de fonctionnalités au niveau de la sécurité dans le protocole SMB 3 [lien].

Matériel

Prise en charge du module Wi‐Fi/Bluetooth Marvell SD8787 Wi‐Fi/BT chip [lien].

syscall

Cette version du noyau propose un nouvel appel système statx(2). Ce dernier est une amélioration de la fonction POSIX stat(2). Pour rappel, la fonction int stat(const char *pathname, struct stat *buf) va nous permettre de connaître un certain nombre de métadonnées sur le fichier qui se trouve à la position indiquée par pathname. On retrouve dans la structure stat passée en paramètre, le numéro du nœud d’index (inode), la taille, le propriétaire et le groupe du fichier. En plus de la fonction stat(2), POSIX décrit la fonction fstat(2) qui prend en paramètre un descripteur de fichier à la place du nom du fichier et la fonction lstat(2) qui, lorsque le nom pointe un lien symbolique, ne suit pas le lien mais fournit les informations du lien lui‐même.

Le nouvel appel est de la forme int statx(int dfd, const char *filename, unsigned atflag, unsigned mask, struct statx *buffer). En plus des paramètres filename et du tampon buffer qui gardent les mêmes fonctions (même si le tampon utilise un nouveau type de structure), on trouve :

• dfd : si l’on fournit un nom de fichier NULL, c’est le descripteur dfd qui est lu (équivalent à fstat(2)) ;
• atflag : si l’on fournit un atflag équivalent à 0 et qu’on lui passe un lien symbolique, c’est bien le lien qui est analysé (équivalent à lstat(2)) ;
• mask : permet de modifier le comportement de l’appel. Avec AT_NO_ATTR_SYNC, cela autorise le système de fichiers à faire des approximations. C’est particulièrement intéressant dans le cas des systèmes de fichiers réseau comme NFS ou CIFS. Le masque AT_FORCE_ATTR_SYNC permet l’exact inverse.

La nouvelle structure statx permet quant à elle d’obtenir plus d’informations, comme la date de création du fichier et les attributs de celui‐ci. Le système de fichiers peut indiquer quelles informations il prend en charge ou non et il est possible d’étendre la structure. Pour faire les choses proprement statx(2) est protégé du bogue de l’an 2038 et le tampon a la même structure quelle que soit l’architecture.

Réseau

ICMP

Le protocole ICMP est connu pour être le protocole utilisé par la commande ping. Les réponses consomment maintenant moins de ressources et des réponses commencent à être supprimées pour, par exemple, éviter la saturation du réseau. (NdM: voir ce commentaire explicatif)

Divers

Diverses autres améliorations ont été faites comme l’optimisation des performances d’envoi pour l’interface réseau virtualisée vhost_net utilisée dans QEMU ou encore dans le filtre BPF (utilisé dans le pare‐feu).

Sécurité

Un début d’implémentation de SIPHASH a été réalisé pour sécuriser les numéros de séquence et les syncookies qui protègent contre les attaques par inondation de requêtes SYN.

Statistiques

Il y a eu pour cette version 4.11 du noyau, un total de 12 724 correctifs proposés par 157 entreprises, ce qui correspond à 816 319 lignes modifiées et pas loin de 300 000 nouvelles lignes.
Les trois plus grosses contributions viennent des développeurs d’Intel (12,8 %), Red Hat (8,5 %) et Linaro (5 %).

Au classement par pays, c’est encore la Chine qui a le plus contribué à cette version, avec 975 correctifs (7,66 %), suivie par l’Allemagne : 960 correctifs (7,54 %) et les États‐Unis : 686 (5,39 %). Un total de 40 nations ont participé par leurs travaux à ce noyau, dont la France avec 480 correctifs (3,77 %).

Aller plus loin

• Dépêches des noyaux précédents (292 clics)
• Site officiel du noyau Linux (277 clics)
• L’article de KernelNewbies (281 clics)
• CNX-software (122 clics)