Sortie du noyau Linux 4.0

La sortie de la version stable 4.0 du noyau Linux a été annoncée le 12 avril 2015 par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site kernel.org. Le détail des évolutions, nouveautés et prévisions se trouve dans la seconde partie de la dépêche.

Sommaire

• En bref
• Annonces des versions candidates par Linus Torvalds
  • RC-1
  • RC-2
  • RC-3
  • RC-4
  • RC-5
  • RC-6
  • RC-7
  • Version finale
• Les nouveautés
  • Architecture
    • ACPI
    • Mise à jour du noyau à la volée
      • Intérêt et champ d’application
      • Historique
      • Implémentation
      • Concrètement, que voit l’utilisateur ?
  • Développeurs
    • KASan : Kernel Adress Sanitizer
    • Suppression de l’appel système remap_file_pages()
    • Nouvelles fonctionnalités pour l’outil perf
    • Read-Copy-Update (RCU) pour fils d’exécution à priorité temps réel
    • Tinyfication : suppression possible d’une version du sous‐système RCU
    • Vérifications supplémentaire lors d’un appel à might_sleep()
    • Méchanisme devfreq_event
  • Périphériques d’entrée
    • Pavé tactile FocalTech
  • Pilotes graphique libres
    • DRM (Direct Rendering Manager)
    • AMD/ATI (pilote radeon)
    • Intel (pilote i915)
    • NVIDIA (pilote nouveau)
    • Pilotes grahiques pour systèmes monopuces
      • Qualcomm (pilote msm)
      • NVIDIA (pilote tegra)
      • Renesas (pilote rcar-du)
      • Samsung (pilote exynos)
  • Réseau
    • Algorithmes TCP d’évitement de congestion
    • Gestion des espaces de noms pour TIPC
    • Identifiants de flux pour Open vSwitch
    • Gestion des filtres eBPF pour le contrôle du trafic réseau
  • Sécurité
    • Prise en compte des puces TPM 2.0
    • Version 2.2.0 de la bibliothèque seccomp
    • LSM
    • SELinux
      • Gestion de Binder
      • SMACK
    • Liste non exhaustive des vulnérabilités corrigées
  • Systèmes de fichiers
    • Lazytime
    • Btrfs
    • Ceph
    • F2FS
    • OverlayFS
    • pNFS
  • Virtualisation
    • VirtIO
    • KVM
    • Xen
  • Pages de manuel
• Le bilan en chiffres
• Appel à volontaires

En bref

Après de longues discussions, ce noyau n’est pas le 3.20, mais le 4.0. Rétroactivement, on pourrait justifier cela grâce à l’arrivée de la modification à chaud du noyau, ou que compter au‐delà de vingt n’est pas une sinécure : c’est selon.

La nouveauté principale du noyau est la mise à jour du noyau à la volée. Du coté des pilotes graphiques, la gestion atomique du mode graphique a été introduite en mode expérimentale. Pour finir, le drapeau lazytime a été introduit dans la couche d'abstraction VFS afin de booster les performances de atime.

Annonces des versions candidates par Linus Torvalds

RC-1

La version RC1 est sortie le dimanche 22 février 2015 :

Voyons quelle proportion, le cas échéant, va être cassée par ce changement de version.
Probablement moins que pendant la période du 3.0, mais j’imagine bien quelqu’un cherchant des versions significatives.

Parce que le peuple a parlé, et même si la plupart des interventions n’étaient qu’un charabia complet, les nombres ne mentent pas. Le peuple a préféré 4.0, et ce sera 4.0. À moins que quelqu’un ne surgisse avec un bon argument contre.

Jusque là, les arguments contre semblent avoir été « un numéro majeur devrait aller avec une fonctionnalité majeure ou une rupture de compatibilité », ce qui montre le peu que les gens connaissent. Nous ne cassons pas la compatibilité, et nous n’avons pas fait de sorties basées sur une fonctionnalité depuis, en fait, le début.

D’un autre côté, l’argument le plus fort pour certains des partisans d’une version 4.0 semble avoir été le souhait de voir une 4.1.15 — parce que « c’était la version de Linux que Skynet utilisait pour le T-800 ».

Donc, au final, je ne voudrais pas trop lire [le destin] dans ce numéro.

Sur le plan réellement technique, c’était plutôt une petite version. En considérant les normes actuelles. Elle est assurément notablement plus petite que certains noyaux récents, même si nous parlons de ~9k de modifs hors fusion plutôt que de 10-11k, donc ce n’est pas comme s’il y avait une énorme différence.

L’infrastructure de mise à jour à chaud a fait la une, mais mes fonctionnalités favorites sont personnellement les quelques nettoyages de mémoire virtuelle, par lesquels cette sortie nous débarrasse du code de correspondance non linéaire largement inutilisé (remplacé par une émulation avec beaucoup de mises en correspondance plus petites) et unifie la prise charge des tables de pages pour NUMA et PROTNONE.

Mais personne ne devrait le remarquer. Parce que passer en 4.0 ne veut pas dire que nous avons changé de quelque manière que ce soit ce que voient les gens. Ça n’est que la continuité, avec seulement des plus petits chiffres, de manière à ce que je puisse faire des sorties sans avoir à retirer à nouveau mes chaussettes.

Allez‐y, testez. Les arborescences Git sont déjà là, l’archive tar et les correctifs vont sortir au moment où j’écris. Bien sûr, avec le changement de version, je suppute qu’il y aura quelques hoquets avec les miroirs de kernel.org, même si Konstantin pense que tous les scripts sont déjà prêts. Donc, si vous ne trouvez pas les archives tar et les correctifs, soit j’ai déconné, soit c’est Konstantin. :)

Linus

RC-2

La version RC2 est sortie le mardi 3 mars 2015 :

Ainsi la RC2 a loupé le créneau habituel du dimanche après‐midi, parce que j’ai passé la plupart du week‐end à déboguer un problème qui apparaissait sur un vieux Mac Mini que j’avais dans le coin, et que je déteste faire des sorties, même en début de RC, avec des problèmes sur des machines auxquelles j’ai directement accès. Même si cela a seulement affecté de vieilles machines que les vrais développeurs ont peu de chance d’avoir ou du moins d’utiliser.

Aujourd’hui, j’ai le correctif de Daniel Vetter le corrigeant, donc, plutôt que de faire une RC2 du dimanche soir, c’est une du mardi matin. Allez la récupérer. Elle fonctionne mieux grâce à ce retard.

À part ce petit correctif d’une ligne pour i915 ? Pas grand chose en fait. Ce fut une semaine très calme, pour un début de processus de sortie. Bien sûr, la 3.19-rc2 était encore plus petite, donc cela poursuit une tendance, mais c’était la semaine de Noël. J’espère que ce faible volume est juste dû au fait que la fenêtre de fusion du 4.0 elle‐même était quelque peu plus calme que pour les toutes dernières sorties. Mais je suppute que la vraie raison est la mise en attente des arborescences des pilotes et du réseau de GregKH et davem, qui n’ont pas eu le temps d’être prêtes pour la RC2.

On verra.

En tout cas, la version courte du journal des modifications est en annexe, et les tests sont grandement appréciés.

Linus

RC-3

La version RC3 est sortie le dimanche 8 mars 2015 :

De nouveau en phase avec le calendrier des sorties du dimanche après‐midi, puisqu’il n’y a rien eu de particulièrement étrange cette semaine, et aucun bogue de dernière minute dont j’aurais eu connaissance ou que j’aurais voulu résoudre qui aurait repoussé l’échéance.

En termes de taille, on est aussi dans la normale, pas aussi petit que la RC2. Cela s’explique facilement par la récupération des correctifs de David et Greg (puisque le réseau et les pilotes ont tendance à être les deux plus grosses parties).

Et la répartition des correctifs est plutôt classique également : à peu près deux tiers de pilotes (processeurs graphiques, réseau, USB, staging, son, divers), le reste concernant les systèmes de fichiers (principalement NFS et Btrfs), des mises à jour d’architectures (ARC, x86, ARM, PowerPC), du réseau et de la documentation.

En d’autres termes, tout semble complètement normal à cette étape du processus de sortie.

S’il vous plaît, testez‐moi tout ça,

Linus

RC-4

La version RC4 est sortie dimanche 15 mars 2015 :

Hmm. Rien de particulièrement étrange cette semaine non plus, avec peut‐être juste une mise à jour légèrement plus grosse que prévue d’un système monopuce ARM. Donc, « seule » la moitié du correctif est composée de mises à jour de pilotes, la moitié restante étant des changements dans ARM.

Le reste est l’habituel mélange de divers correctifs — quelques autres architectures (S/390, Nios II), du réseau, du cœur de noyau et de la mémoire virtuelle, quelques mises à jour de la documentation. Rien ne se détache particulièrement ici. Le journal court est en annexe, je pense qu’on se débrouille bien à cette étape du cycle de sortie.

Linus

RC-5

La version RC5 est sortie dimanche 22 mars 2015 :

Alors, la RC5 est presque exactement de la même taille que la RC4. Je serais plus heureux si les RC rétrécissaient, mais je suppose que je devrais être reconnaissant qu’au moins elles ne semblent pas grossir.

Il n’y a rien de particulièrement inquiétant, bien que j’essaie toujours de penser à la régression de performance de l’équilibrage NUMA. Ça ne devrait pas être bloquant, mais c’est ennuyeux, et je veux que ce soit corrigé.
On y arrivera, j’en suis certain.

En attendant, la rc5 est principalement constituée de mises à jour de pilotes (à travers toute l’arborescence des pilotes : pilotes graphiques, USB, son, réseau, HID, entrées, contrôleurs de broches [pinctrl], etc.) avec quelques mises à jour d’architectures (x86, ARM, ARM64, SPARC) et quelques corrections de systèmes de fichiers (principalement Btrfs). Et, également, un soupçon de corrections du code réseau, hors pilotes.

Le journal court des modifications est en annexe, bien qu’il ne soit pas particulièrement intéressant. La plupart des gros correctifs étaient des retours en arrière, comme il se doit à cette étape.

Linus

RC-6

La version RC6 est sortie dimanche 29 mars 2015 :

Ça se calme gentiment, et il y a des corrections un peu partout. La régression de performance de l’équilibrage NUMA est corrigée, et les choses s’améliorent à nouveau de manière générale. Il y a eu un certain nombre de problèmes avec i915 et une double faute KVM qui a fait que pendant un bon moment j’étais quasi certain que ce serait un cycle qui irait jusqu’à une RC8, mais cela pourrait ne pas s’avérer nécessaire.

À part les problèmes susmentionnés, le gros de cette sortie est constitué principalement de petites correction de divers pilotes et de mises à jour d’architectures. Le journal court donne un meilleur aperçu de ce qu’il s’est passé.

Mais, s’il vous plaît, testez bien cette RC, et braillez s’il y a des régressions que nous aurions ratées.

Linus

RC-7

La version RC7 est sortie le lundi 6 avril 2015 :

Bon, la RC7 a un jour de retard, pour cause de dîner de Pâques. Pour compenser, elle inclut quelques corrections supplémentaires.

Mais elle est encore assez petite, et on est en bonne voie pour la 4.0 le week‐end prochain. Il y a une minuscule probabilité que je décide de repousser la 4.0 d’une semaine, simplement parce que je voyage la semaine d’après, et je pourrais vouloir éviter d’ouvrir la fenêtre d’intégration. Nous verrons comment je le sens le week‐end prochain.

En tout cas, rien de particulièrement étrange dans cette RC7. Elle contient à peu près trois quarts de mises à jour de pilotes (la plupart étant des pilotes réseau, mais il y a des trucs un peu partout : pilotes graphiques, IIO, entrées, USB…). Le reste est composé de quelques petites corrections sur x86, un peu de réseau, une correction concernant lazytime et de la documentation.
Et tout ça est assez petit.

Linus

Version finale

La version finale est sortie le dimanche 12 avril 2015 :

Alors, j’ai décidé de sortir le 4.0 selon le calendrier habituel, parce qu’il n’y avait vraiment aucun problème connu et, bien que je voyagerai à la fin de la semaine à venir en raison de la visite d’une université, j’espère que cela n’affectera pas trop la fenêtre de fusion.
On verra.

Linux 4.0 était une version assez petite, à la fois dans linux-next et par sa taille finale, bien qu’évidemment, « petit » est tout relatif. Elle fait tout de même plus de 10 000 commits non fusionnés. Mais, nous avons clairement eu de plus grosses versions (et, à en juger par linux-next, la 4.1 va être l’une des plus grosses).

Ce qui est une bonne chose. Cela colle parfaitement à « la v4.0 est supposée être une version stable », et absolument pas l’objet de nouvelles fonctionnalités expérimentales, etc. Je suis personnellement bien plus satisfait par les sorties planifiées que par la mauvaise époque où nous avions des sorties basées sur les fonctionnalités.

Ceci dit, il y a quelques éléments de numérologie intéressants amenés par la 4.0. En ne regardant que les statistiques dans git, cette version n’est pas juste celle faisant passer la barre du demi‐million de commits au total, mais également la limite des 4 millions d’objets git. De manière intéressante (si l’on regarde les modèles numériques), Linux 3.0 était le moment où nous nous avons dépassé le quart de million de commits et 2 millions d’objets git, donc il y a là un joli (et complètement non intentionnel) modèle concernant le dépôt git du noyau.

[Une autre rapide note historique de numérologie de bas de page : l’ancien historique de l’arbre BK approchait la limite de commits des 16 bits que BK avait à l’origine. Donc, ce « quart de million de commits » est vraiment pas mal du tout. Pendant toutes les années sous BK nous n’avons eu que 65 000 commits. Bien sûr, nous n’avons utilisé BK que pendant trois ans, et nous sommes maintenant avec Git depuis presque dix ans, mais tout de même — cela montre à quel point le processus global de développement s’est énormément accéléré].

En termes de fonctionnalités, le 4.0 n’a rien de vraiement spécial. On a beaucoup parlé de la nouvelle infrastructure de correction du nouveau noyau, mais en réalité, ce n’était pas la seule raison du changement de version, on a eu de bien plus gros changements dans d’autres versions. Donc, c’est davantage une version de « solide amélioration du code ».

Ramenez‐le et amusez‐vous,

Linus « nous sommes tous des moutons » Torvalds

N. D. T . : La version 4.0 a été nommée « Hurr durr I’m a sheep », soit « [onomatopées de votre choix] je suis un mouton » par Linus.

Les nouveautés

Architecture

ACPI

Les portables de marque Toshiba seront beaucoup mieux gérés : le pilote toshiba_acpi gère maintenant l’activation du mode « éco », de l’USB 3, de la charge rapide USB en veille, etc.

Pour avoir eu le plaisir d’utiliser une machine concernée depuis neuf mois, j’ajoute que ce n’est pas rien : au départ, le pavé tactile n’était pas géré (arrivé avec le noyau 3.18), l’écran ne se rallumait pas après une mise en veille, et la machine consommait deux fois plus de batterie.

Mise à jour du noyau à la volée

Intérêt et champ d’application

Un nouveau système de mise à jour du noyau à la volée — c’est‐à‐dire sans redémarrer l’ordinateur, et donc sans interrompre (complètement) les services — a fait son apparition, sous le modeste nom de livepatch. La fonctionnalité est particulièrement intéressante pour les serveurs et probablement pour un grand nombre d’autres ordinateurs.
Comme on le verra plus bas, ce système de mise à jour n’est pas universel et ne permettra pas de mettre à jour l’ensemble du noyau, mais permettra notamment, on peut l’espérer, de mettre en œuvre des correctifs de sécurité sans redémarrer les systèmes, donc sans fenêtre de maintenance.

Historique

Au commencement, était kSplice, une solution de mise à jour à chaud du noyau révolutionnaire, ultérieurement rachetée par Oracle pour utilisation exclusive avec sa distribution, fermant la porte à Red Hat, SUSE, etc. S’ensuivirent des violations de GPL (temporaires), et d’autres piques à Red Hat.

L’année dernière, Red Hat et SUSE ont annoncé quasiment en même temps, respectivement kpatch et kGraft, toutes deux des solutions de mise à jour à chaud. Étant données les politiques respectives des deux entreprises, on pouvait espérer qu’une des solutions au moins se retrouve dans la branche principale du noyau.

Et ça n’a pas tardé, Red Hat et SUSE ont travaillé de concert en prenant les meilleurs élements de kpatch et kGraft.

Red Hat a eu l’idée d’utiliser une implémentation plus simple, qui utilise stop_machine(), c’est‐à‐dire qui arrête l’ensemble du système pendant quelques millisecondes, regarde la pile, et change le code de la fonction, si c’est sans danger, puis enlève le code de l’ancienne fonction, devenu inutile.

De son côté, SUSE décida de travailler au niveau des tâches elles‐mêmes : plutôt que d’arrêter le système, les tâches sont arrêtées une par une, et si une tâche doit appeler la fonction à mettre à jour, alors il est fait en sorte que ce soit la nouvelle qui soit appelée. Dès que chaque tâche a été traitée, l’ancienne fonction est enlevée, et le système tourne effectivement avec le nouveau code. L’avantage est que le système n’est arrêté à aucun moment, mais que la mise à jour peut prendre plusieurs minutes avant de se propager, car il faut également envoyer un signal de réveil aux tâches endormies pour garantir qu’elles ont été mises à jour. Regardez cette excellente présentation de kGraft à Kernel Recipes 2014 (en anglais) pour plus de détails.

Red Hat et SUSE ont tous deux accepté de migrer leurs solutions vers livepatch dès que celui‐ci sera suffisamment complet.

Implémentation

Les deux solutions sont basées sur ftrace, l’outil de traçage interne au noyau qui permet déjà de mettre à jour à chaud l’incipit des fonctions du noyau, pour tracer leurs appels à la demande. livepatch utilise une des toutes dernières évolutions de ftrace qui permet à plusieurs sous‐systèmes du noyau d’utiliser en même temps la mise à jour à chaud dynamique.

L’implémentation de livepatch qui vient d’arriver dans le noyau a pour but de combiner l’avantage des deux méthodes de kGraft et kpatch. Dans un premier temps, cela ne fonctionne que sur l’architecture x86, mais du travail est en cours pour PowerPC, S390 et ARM.

Concrètement, que voit l’utilisateur ?

Vous payez un abonnement à Oracle, Red Hat ou SUSE et votre serveur se met à jour tout seul.
Chaque mise à jour est en fait un nouveau module noyau à insérer (donc visible avec lsmod). Ce module utilise les API du sous‐système livepatch pour aller remplacer l’implémentation d’une fonction à mettre à jour, par une nouvelle fonction présente dans le module. Cela veut donc dire qu’on ne peut pas, par exemple, mettre à jour une structure (avec un nouveau champ), ou appliquer la totalité des mises à jour ainsi. C’est une opération coûteuse, car le module correctif est fait manuellement à chaque fois. À terme, cela devrait néanmoins permettre de corriger une partie des failles de sécurité découvertes dans le noyau sans devoir redémarrer la machine.

Voir l’exemple dans ce correctif et le message de ce correctif de fusion.

Développeurs

KASan : Kernel Adress Sanitizer

KASan est l’équivalent pour le noyau d’ASan (Address Sanitizer). Il permet de détecter lorsque le noyau accède à des zones mémoire qu’il n’a pas explicitement alloué auparavant. Il a déjà été utilisé avec succès pour trouver des bogues dans le noyau (parfois en combinaison avec Trinity).

Tout ceci est réalisé à l’aide d’une combinaison de nouvelles fonctionnalités ajoutées au compilateur C de GCC pour suivre les accès à la mémoire. Lorsqu’un accès invalide est effectué, un message complet de la situation est affiché dans le journal système du noyau.

Pour cela, le noyau établit une « carte » représentant à l’échelle un huitième la mémoire adressable. Pour l’instant, seule l’architecture x86_64 est gérée. Chaque octet de la carte code la validité de l’accès à la zone de mémoire auquel il correspond. Cette carte est mise à jour par le noyau lors des allocations et désallocations mémoire et est consultée avant chaque accès à la mémoire.

KASan bénéficie du fait qu’une partie importante de ses fonctionnalités est implémentée directement dans le compilateur et ajoutée à la compilation dans le noyau. Il est donc plus rapide que kmemcheck, mais il ne peut pas détecter l’accès à des zones de mémoire non initialisées. D’autre part, DEBUG_PAGEALLOC et SLUB_DEBUG sont plus rapides que KASan, mais ils sont moins précis que celui‐ci.

Plus de détails dans l’article sur LWN.net : _The kernel address sanitizer.

Suppression de l’appel système remap_file_pages()

Comme annoncé l’an dernier, la mise en œuvre de l’appel système remap_file_pages() a été supprimée. À sa place, on a une fonction qui émule la même fonctionnalité utilisant de multiples zones de la mémoire virtuelle, de sorte que les (rares) applications utilisant cet appel devraient continuer à fonctionner. À noter qu’il n’y a pas de ruptures d’API ou d’ABI.

[article de LWN.net]

Nouvelles fonctionnalités pour l’outil perf

L’outil perf a bénéficié d’une nouvelle série d’améliorations diverses recensées dans le message du correctif de fusion.

Read-Copy-Update (RCU) pour fils d’exécution à priorité temps réel

Le noyau peut être compilé pour que le méchanisme de synchronisation des fils d’exécution (threads) appelé read-copy-update (RCU) à délai de grâce (grace-period-handling) fonctionnent avec des priorités temps réel. La plupart des systèmes n’en ont pas besoin, mais certaines charges de travail élevées peuvent tirer profit de cette fonctionnalité.

Tinyfication : suppression possible d’une version du sous‐système RCU

Le sous‐système read-copy-update gérant la mise en veille peut être compilé hors du noyau pour libérer de la place sur les systèmes allégés où il peut ne pas être nécessaire.

Voir l’article de LWN.net pour plus de détails.

Vérifications supplémentaire lors d’un appel à might_sleep()

La fonction de débogage might_sleep() va maintenant vérifier le débordement de pile. En effet, il semble que souvent, ce qui ressemble à un appel inapproprié à une fonction de mise en veille est en fait un artefact causé par un débordement de pile.

Méchanisme devfreq_event

Le nouveau mécanisme devfreq_event fournit un moyen pour les dispositifs en charge de la gestion d’énergie d’obtenir des données brutes sur les performances et l’utilisation de ces dispositifs.

Périphériques d’entrée

Pavé tactile FocalTech

Une bonne nouvelle pour les possesseurs de portables Asus récents, la gestion des pavés tactiles FocalTech arrive enfin dans cette version du noyau. Auparavant, le périphérique était utilisable au travers de son émulation qui le faisait passer pour une souris USB générique. Cette prise en charge basique était déjà activée depuis le noyau 3.18, mais ne permettait que la reconnaissance d’un seul point de contact et des boutons physiques, le reste n’étant accessible qu’au travers d’un protocole propriétaire. C’est Mathias Gottschlag qui s’est attelé à la tâche de la rétro‐ingénierie et, alors que tout le monde s’attendait à un travail de longue haleine, il a déchiffré le protocole dans la journée. L’intégration a été plus longue, le temps de tester le pilote sur le plus de configurations possibles, les dernières modifications sont même arrivées dans la RC4.

Le pilote noyau étant compatible Synaptics, c’est donc un pavé tactile entièrement fonctionnel et réglable à souhait au travers de synclient qui nous arrive.

Pilotes graphique libres

Divulgation complète : cette partie a été écrite par le contributeur habituel, mais celui‐ci travaille maintenant pour Intel. Son discours peut donc être biaisé. Ce contributeur a cependant affirmé sur son blog qu’il resterait factuel et juste envers tous les pilotes, comme il s’est efforcé de le faire depuis le début de ses contributions. Cette partie reflète uniquement son opinion et pas celle de son employeur.

DRM (Direct Rendering Manager)

Les travaux sur la gestion atomique du mode graphique (introduite partiellement dans Linux 3.19) s’achèvent dans cette nouvelle version grâce à l’arrivée d’un nouveau IOCTL qui permet enfin d’effectuer un changement atomique. Couplés aux changements proposés par Rob Clark, qui rendent l’état entièrement stocké sous forme de propriété, il devient possible d’utiliser cette gestion atomique depuis l’espace utilisateur ! Cette fonctionnalité reste cependant encore masquée derrière le paramètre drm.atomic=1, probablement en attendant que plus de tests soient faits sur l’interface avant que celle‐ci ne devienne publique. Pour plus d’informations sur l’intérêt d’une gestion atomique du mode graphique, vous pouvez consulter la dépêche précédente sur le noyau 3.19. Pour plus d’informations sur les changements apportés spécialement dans cette version du noyau 4.0, vous pouvez consulter l’article de Daniel Vetter sur le sujet.

Comme d’habitude, cette nouvelle version du noyau apporte la gestion de nouveaux panneaux et écrans. Pour plus d’informations, vous pouvez consulter la demande d’integration.

Pour plus d’informations, vous pouvez consulter la demande d’intégration DRM.

AMD/ATI (pilote radeon)

La nouveauté principale de ce noyau pour le pilote Radeon est l’amélioration du code de gestion du son via HDMI et l’activation de la sortie audio Display Port pour toutes les générations de cartes qui le gèrent [commits].

Une autre nouveauté importante est l’intégration des modifications nécessaires pour faire fonctionner l’extension OpenGL 4.0 ARB_draw_indirect. Le code pour cette extension est déjà présent dans Mesa 3D.

La vitesse des ventilateurs pour les familles Southern Islands et Canary Islands (voir les désignations commerciales) peut maintenant être gérée manuellement par l’utilisateur, grâce à l’interface HWMON. La gestion automatique du ventilateur est, quant à elle, présente, mais désactivée par défaut, car elle est encore instable.

Pour plus d’informations, vous pouvez consulter la demande d’intégration radeon.

Intel (pilote i915)

La conversion du pilote i915 vers la gestion atomique du mode graphique continue. Dans cette nouvelle version, le pilote permet la mise à jour des plans graphiques de façon atomique. Il manque cependant encore la gestion asynchrone de cette mise à jour (qui sera disponible dans Linux 4.1) ainsi que la mise à jour des paramètres du filigrane (watermark).

Du côté de la gestion du mode graphique, un gros travail de réorganisation du code a été fait. Il reste cependant encore à retravailler la gestion des boucles à phase asservie (PLL) du bloc d’affichage, afin d’obtenir la gestion atomique des contrôleurs d’affichage vidéo CRTC. Ce travail a créé une régression dans le cycle RC5 qui a même pu être reproduite par Linus, sans pour autant que celui‐ci ne se mette en colère sur la fragilité de l’étape intermédiaire d’atomisation du mode graphique.

Une autre nouveauté est la gestion des listes d’exécution Execlists. Celles‐ci sont un nouveau mode d’envoi de commandes au processeur graphique introduit dans le matériel, en parallèle de l’ancien mode dans les processeurs Broadwell, et unique moyen d’envoyer des commandes aux processeurs graphiques Skylake et suivants. Ce nouveau mode est activé par défaut pour les processeurs qui le gérent.

La gestion du PPGTT (Per‐Process Graphics Translation Table), carte de correspondance mémoire vidéo par processus, est maintenant activée par défaut sur les processeurs gérant les Execlists. Il reste encore des bogues à corriger sur les processeurs plus anciens.

Si vous voulez en savoir plus, vous pouvez consulter l’habituel compte‐rendu détaillé des modifications de Daniel Vetter (mainteneur i915).

NVIDIA (pilote nouveau)

Peu de nouveautés majeures dans cette nouvelle version, à cause du travail nécessaire pour la gestion des nouveaux processeurs graphique Maxwell. Cependant, Ben Skeggs a profité du calme pour unifier les noms des différents composants avec les noms utilisés par NVIDIA. Cela va permettre une communication plus simple avec les ingénieurs de chez NVIDIA.

Ben Skeggs a également commencé le travail de séparation entre DRM et NVKM. À terme, cela permettra à plusieurs instances de Nouveau-DRM s’exécutant dans différentes machines virtuelles de pouvoir fonctionner en parallèle, et ainsi fournir une accélération complète dans chaque machine virtuelle. Pour l’instant, ce travail a uniquement consisté en le renommage des différents fichiers et structures.

Pour finir, les ingénieurs de NVIDIA ont ajouté la gestion manuelle du recadencement (reclocking) pour les processeurs graphiques monopuces GK20A. Ils ont également décidé de fusionner le module de détection de plate‐forme (nouveau_platform.ko) avec nouveau.ko afin, entre autres, de simplifier la gestion des symboles.

Pilotes grahiques pour systèmes monopuces

Qualcomm (pilote msm)

Le pilote Linux pour les processeurs graphiques Adreno de Qualcomm s’améliore avec la gestion du eDP et des curseurs matériels mdp5. Ces derniers, ainsi que les curseurs matériels mdp4, se voient également dotés de la gestion du format YUV.

Pour plus d’information, vous pouvez consulter la demande d’intégration msm. Pour avoir un compte‐rendu de l’état du pilote msm + freedreno, vous pouvez consulter l’article récapitulatif de LWN.net sur la présentation de Rob Clark, le créateur initial et principal du projet.

NVIDIA (pilote tegra)

Du côté des processeurs graphiques Tegra de NVIDIA, la nouveauté principale est la conversion (semble‐t‐il complète) vers la gestion atomique du mode graphique. Bravo à Thierry Reding pour son travail !

Le pilote de blocs host1x a également été amélioré afin de gérer la mise en veille et le réveil des différents blocs qu’il contrôle.

Pour plus d’information, vous pouvez consulter la demande d’intégration tegra.

Renesas (pilote rcar-du)

Le pilote du processeur graphique de Renesas a reçu quelques améliorations liées à l’affichage, telles que la gestion des modes entrelacés ou la possibilité d’utiliser une horloge externe. Il est également maintenant possible de chaîner un encodeur HDMI après un encodeur LVDS.

Pour plus d’information, vous pouvez consulter la demande d’intégration rcar-du.

Samsung (pilote exynos)

La nouveauté principale du pilote pour les processeurs graphiques des systèmes monopuces de Samsung est la gestion du contrôleur d’affichage DECON qui est introduit dans les Exynos7. Ce contrôleur est apparemment très différent du contrôleur précédent qui avait été introduit dans les Exynos4.

La gestion atomique du mode graphique devait faire partie de cette nouvelle version, mais trop de bogues étaient encore présents pour rendre ce code disponible.

Pour plus d’informations, vous pouvez consulter la demande d’intégration.

Réseau

Algorithmes TCP d’évitement de congestion

Il est maintenant possible de choisir un algorithme d’évitement en fonction du destinataire, simplement via la table de routage. Par exemple :

ip route add 10.0.42.0/16 dev eth0 congctl hybla

Gestion des espaces de noms pour TIPC

L’implémentation du protocole de communication transparente interprocessus — Transparent Inter‐Process Communication protocol — gère désormais correctement les espaces de noms.

Identifiants de flux pour Open vSwitch

Le sous‐système Open vSwitch peut maintenant générer ses propres identifiants de flux (flow IDs) pour identifier les échanges réseau dans le trafic de commandes en mode utilisateur. Les performances de certaines opérations peuvent être améliorées jusqu’à 40 % grâce à cette amélioration.

Gestion des filtres eBPF pour le contrôle du trafic réseau

Le sous-système de contrôle du trafic prend désormais en charge l’utilisation de filtres écrits dans le langage de la machine virtuelle eBPF.

Sécurité

Prise en compte des puces TPM 2.0

Les puces Trusted Platform Module 2.0 sont prises en charge [correctifs : 1, 2, 3].

Version 2.2.0 de la bibliothèque seccomp

Cette version de seccomp ajoute [annonce] :

• la prise en charge des architectures [AArch64, MIPS, MIPS64, MIPS64 N32 ;
• la gestion du nouvel appel système seccomp() et de la synchronisation des filtres pour les programmes à multiples fils d’exécution (multithreads) [Cf. dépêche 3.17] ;
• l’inclusion des bibliothèques de liaison (bindings) pour Python ;
• la mise à jour de la liste des appels système disponibles (noyau 3.19).

LSM

David Howells a corrigé la façon dont les différents modules LSM effectuaient certaines vérifications sur les nœuds d’index (inodes) pour améliorer la prise en compte du système de fichiers OverlayFS [correctifs : 1, 2, 3, 4, 5 et 6].

SELinux

Gestion de Binder

Le mécanisme de communication interprocessus Binder, propre à Android, est maintenant contrôlable à l’aide des « crochets » LSM et la prise en charge de SELinux a été ajoutée dans cette version [correctif].

SMACK

La gestion du marquage de paquets réseau à l’aide de secmark de Netfilter a été ajoutée pour les paquets locaux en IPv4 et IPv6 [correctif]. Les étiquettes CIPSO sont utilisées dans les autres cas [correctif].

Les opérations sur les fichiers et les accès bidirectionnels à un socket UNIX sont désormais contrôlées et auditées correctement [correctifs : 1, 2 et 3].

Un autre cas particulier où une zone de mémoire partagée liée à un fichier situé sur un tmpfs pouvait se retrouver avec la mauvaise étiquette a été corrigé [correctif].

L’utilisation de KASan a permis de corriger un cas potentiel d’utilisation d’une zone mémoire après qu’elle a été libérée [correctif].

Liste non exhaustive des vulnérabilités corrigées

• CVE-2014-8159 [correctif] ;
• CVE-2015-2150, XSA-120 [correctif] ;
• CVE-2015-1593 [correctif].

Systèmes de fichiers

Lazytime

Sur les systèmes de fichiers POSIX, trois dates sont associées à chaque fichier (en réalité à chaque nœud d’index) : mtime correspond à la date de dernière modification du contenu, ctime correspond à la date de dernière modification des métadonnées (propriétaire, groupe, droits…) et enfin atime correspond à la date du dernier accès.

Le champ atime a été l’objet de nombreuses critiques au cours du temps, chaque lecture du fichier entraînant une opération d’écriture afin de mettre à jour le champ. Pour éviter de multiplier les écritures inutiles, plusieurs stratégies successives ont été développées sous forme d’options de montage des systèmes de fichiers.
Voici un résumé des anciennes solutions (consultez la page de manuel de mount (NdM: remplacement par un lien archive.org) pour avoir des détails) :

• atime et diratime pour le fonctionnement historique ;
• noatime et nodiratime sont les plus simples, le champ atime n’est plus mis à jour en cas d’accès en lecture ;
• relatime pour ne faire les mises à jour de atime que dans le cas où il n’y avait pas eu de lecture depuis la dernière écriture, l’option inverse étant norelatime ;
• strictatime pour forcer le mode atime.

Une nouvelle option de montage des systèmes de fichiers a été intégrée au noyau : lazytime. Cette dernière maintient la date de dernier accès dans atime, mais la conserve uniquement en mémoire. Tout le système voit donc des champs atime mis à jour conformément à la norme. Ces modifications sont reportées sur le disque dans les cas suivants :

• le nœud d’index doit être modifié pour toute autre raison ;
• l’application force une synchronisation (fsync, syncfs ou sync) ;
• en cas de manque de mémoire ;
• toutes les 24 heures (ext4 uniquement pour le moment, c’est le comportement récent de relatime sur ce système de fichiers).

L’objectif est de réduire les écritures disque liées à atime de manière plus efficace que relatime, en profitant des écritures obligatoires, et de gagner en précision et fonctionnalités, en rétablissant le comportement historique de atime.

Cette option, initialement développée pour ext4 a finalement été remontée au niveau de la couche [VFS] pour permettre à tous les types de systèmes de fichiers d’en profiter. Pour ceux qui sont intéressés, LWN.net y a dédié un article (en anglais).

Btrfs

Entre autres, grâce au déploiement de Btrfs au sein de grosses grappes de serveurs chez Facebook, Josef Bacik a corrigé un problème dans lequel le système de fichiers retournait à tort des erreurs de type « manque de place » (ENOSPC).

Le code de gestion des niveaux RAID 5 et 6 a été nettoyé. Un bogue a cependant été introduit et a retardé la demande de fusion. Le correctif a, quant à lui, été édité le lendemain même.

Ceph

RBD (la version « périphérique de type bloc » du client Ceph) exploite maintenant le composant « multi‐queue » du noyau, ce qui devrait en améliorer les performances. De plus, l’option tcp_nodelay est maintenant prise en compte, afin de réduire la latence.

De son côté, CephFS reçoit de nombreux correctifs.

Pour plus d’informations, veuillez consulter la demande d’intégration.

F2FS

F2FS, le système de fichiers spécialisé pour les mémoires Flash n’a subi que des modifications mineures, nettoyage de code et correction de bogues [demande d’intégration].

OverlayFS

OverlayFS a été intégré dans le noyau 3.18. Ce système de fichiers, principalement utilisé par les distributions sur support autonome (live), s’est vu ajouter la gestion du multicouche en 3.19. Dans ce nouveau noyau est ajoutée la possibilité d’avoir de multiples couches en lecture seule. La couche supérieure accessible en écriture est désormais optionnelle [demande d’intégration].

pNFS

Le sous‐système parallel NFS (pNFS) a obtenu la prise en compte de la disposition FlexFile en cours de développement. Cette disposition permet aux métadonnées de fichiers d’être stockées à un endroit différent du contenu des fichiers.

Virtualisation

VirtIO

Rusty Russel a annoncé l’implémentation de la version 1.0 du standard VirtIO selon les spécifications OASIS.

Ces périphériques dédiés aux environnements virtuels, permettent aux invités d’utiliser des pilotes et mécanismes de découverte standards et documentés, plutôt que des variantes par type de systèmes d’exploitation ou d’environnements.

L’intérêt pour un standard (plutôt qu’un billet de blog et le code) s’est montré avec l’adoption massive de VirtIO. On ne le retrouve pas que dans KVM, il est aussi utilisé dans Xen, VirtualBox, BHyVe (l’hyperviseur de FreeBSD) et même dans les ordiphones, pour communiquer avec les accélérateurs matériels.

Plus de détails dans l’article Standardizing virtio de LWN.net.

KVM

Une amélioration est commune à toutes les architectures, il s’agit d’introduire une scrutation (polling) lorsqu’une instruction d’arrêt HLT (ou équivalent sur d’autres architectures) est exécutée sur l’invité. Cela peut diminuer la latence jusqu’à 50 %. Actuellement, il faut l’activer manuellement, mais le but à terme est d’avoir une activation automatique.

• ARM : émulation du contrôleur d’interruptions GICv3 ;
• S390 (ordinateurs centraux IBM) : une petite victoire pour le développement du noyau Linux, il est maintenant possible d’avoir les identifiants uniques UUID et les noms longs d’invités dans /proc/sysinfo avant que cette fonctionnalité soit disponible dans l’hyperviseur d’IBM ;
• x86 : prise en charge de la journalisation des modifications des pages mémoire (page modification logging), une nouvelle fonctionnalité des processeurs Xeon Broadwell qui accélère le suivi des dirty pages. La virtualisation imbriquée gère l’APICv (des instructions processeur qui accélèrent l’émulation des contrôleurs d’interruptions programmables — APIC — dans les machines virtuelles). Enfin, la latence des minuteurs (timers) d’interruption de type TSC deadline peut être réduite avec une nouvelle option (ces minuteurs permettent de soulager le processeur en demandant au contrôleur d’interruptions de générer une interruption quand le temps est écoulé, au lieu de laisser ce calcul au processeur).

Toutes les architectures ont, bien sûr, reçu des correctifs de bogues.

Xen

Pas de nouveauté pour cette version.

Pages de manuel

Les pages des manuels continuent d’être mises à jour régulièrement. Les dernières nouveautés depuis la dernière mention dans ces colonnes sont listées dans le journal des modifications.

Le bilan en chiffres

En ce qui concerne les statistiques du cycle de développement du noyau 4.0, le site LWN.net a publié son traditionnel article récapitulatif.

En nombre de modifications, on se situe à un peu plus que 10 000, soit environ 2 400 modifications de moins que la version précédente du noyau, ce qui en fait le cycle le plus calme depuis quelques années. Cependant, ce « calme » est relatif puisque 403 000 lignes de code ont été ajoutées alors que 222 000 lignes ont été supprimées, ce qui a conduit à une augmentation nette de 181 000 lignes. Le nombre de contributeurs reste, quant à lui, relativement constant avec 1 403 auteurs.

Pour une fois, le développeur ayant apporté le plus de modifications n’est pas H. Hartley Sweeten, pour son travail de nettoyage des pilotes Comedi, mais Lars‐Peter Clausen, pour son travail de nettoyage et d’amélioration des pilotes audio. Du côté des développeurs ayant le plus modifié de lignes, Ben Skeggs remporte la palme par son travail de renommage des puces et la séparation de NVKM et DRM (voir la sous‐section sur le pilote Nouveau).

Environ 200 entreprises ont participé à l’élaboration de ce noyau. En tête, on retrouve Intel, qui a effectué 11,6 % des changements que l’on peut trouver dans cette nouvelle version. En deuxième place, Red Hat a contribué pour 7,0 % des changements. Il est cependant important de noter que les développeurs sans affiliation ont effectué 8,6 % des modifications, soit juste un peu moins qu’Intel, alors que les personnes non identifiées ont écrit 7,1 % des modifications. On peut donc dire, bien que le noyau soit majoritairement écrit par des employés d’entreprises, que les contributeurs indépendants sont toujours les bienvenus et sont même une majorité !

Appel à volontaires

Cette dépêche est rédigée par plusieurs contributeurs dont voici la répartition :

	Mainteneur	Contributeur(s)
La phase de test	Aucun	Pierre Mazière et Davy Defaud
Arch	Romain Perier	Jiehong
Développeurs	Aucun
Pilotes graphiques libres	Martin Peres
Réseau	Aucun
Systèmes de fichiers	Aucun	Kioob, Mali
Sécurité	Timothée Ravier
Virtualisation	Xavier Claude
Édition générale	Aucun	Martin Peres et Davy Defaud

Un peu de vocabulaire :

• le mainteneur d’une section de la dépêche est responsable de l’organisation et du contenu de sa partie, il s’engage également à l’être dans le temps jusqu’à ce qu’il accepte de se faire remplacer ;
• un contributeur est une personne qui a participé à la rédaction d’une partie d’une section de la dépêche, sans aucune forme d’engagement pour le futur.

Malgré cette équipe importante, beaucoup de modifications n’ont pas pu être expliquées par manque de temps et de volontaires.

Nous sommes particulièrement à la recherche de mainteneurs pour les sections Systèmes de fichiers et Réseau, les précédents n’ayant pas donné de signes de vie pendant la rédaction des dernières dépêches.

Si vous aimez ces dépêches et suivez tout ou partie de l’évolution technique du noyau, veuillez contribuer dans votre domaine d’expertise. C’est un travail important et très gratifiant qui permet aussi de s’améliorer. Il n’est pas nécessaire d’écrire du texte pour aider, simplement lister les commits intéressants dans une section aide déjà les rédacteurs à ne pas passer à côté des nouveautés. La page wiki Rédiger des dépêches noyau signale quelques possibilités pour aider à la rédaction et s’y impliquer (ce que tout inscrit peut faire, ne serait‐ce que traduire^Wsynthétiser les annonces de RC). Essayons d’augmenter la couverture sur les modifications du noyau !

Aller plus loin

• Les noyaux précédents (557 clics)
• Site officiel du noyau Linux (296 clics)
• The 3.20 merge window opens (56 clics)
• 3.20 merge window part 2 (26 clics)
• The end of the 4.0 merge window (58 clics)
• Die Neuerungen von Linux 4.0 (42 clics)
• Kernel newbies : Linux 4.0 (222 clics)