Sortie du noyau Linux 4.3

La sortie de la version stable 4.3 du noyau Linux a été annoncée le 1^er novembre 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, publiée sous licence CC BY-SA, Attribution — Partage dans les Mêmes Conditions.

Note : Tout le monde peut participer à la rédaction de cette dépêche. Vous pouvez même vous proposer pour des sections qui vous intéressent et il y a même de l’aide pour ceux qui voudraient s’y mettre et n’osent pas franchir le pas.

Sommaire

• En bref
• Annonces des RC par Linus Torvalds
  • RC-1
  • RC-2
  • RC-3
  • RC-4
  • RC-5
  • RC-6
  • RC-7
  • Version finale
• Les nouveautés
  • Architecture
    • Une meilleure analyse de performance sur certains processeurs
    • Prise en charge ARMv8.1
    • Amélioration de la prise en charge des systèmes monopuces ARM
    • MIPS n’est pas mort
    • s390
    • AMD Carrizo
  • IPC
  • Développement
  • Pilotes graphiques libres
    • Direct Rendering Manager
    • AMD/ATI
      • Pilote de rendu nouvelle génération (pilote amdgpu)
      • Pilote HSA (pilote amdkfd)
    • Intel (pilote i915)
    • Matrox (pilote mgag200)
    • NVIDIA (pilote nouveau)
    • VMware (pilote vmwgfx)
    • Pilotes graphiques pour systèmes monopuces
      • Qualcomm Snapdragon (pilote msm)
      • Freescale
  • Réseau
    • Prise en charge initiale des VRF
    • IPv6
      • Compilation par défaut dans le noyau
      • Ajout des Identifier Locator Addressing à IPv6 — le retour de la dualité des IP
    • Suivi des connexions Open vSwitch
    • Performances
      • De la qualité de service plus rapide
      • Tunnels légers
    • Nouveau pilote
    • Un peu d’humain
  • Sécurité
    • Anti‐fork‐bomb
    • Révision de l’héritage des capabilities
  • Systèmes de fichiers
    • Btrfs
    • ext3
    • ext4
    • F2FS
    • XFS
  • Virtualisation
    • KVM
    • Xen
• Le bilan en chiffres
• Appel à volontaires

En bref

• Suppression du code d’ext3 étant donné qu’ext4 peut gérer ces partitions.
• Mécanisme anti fork-bomb avec cgroup_pids.
• Meilleure migration à chaud de machines virtuelles grâce au passage des page faults en espace utilisateur.
• Adressage d’un réseau local IPv6 par Identifier Locator Addressing.

Annonces des RC par Linus Torvalds

RC-1

La version RC-1 est sortie le samedi 12 septembre 2015 :

Aujourd’hui, cela a été plutôt calme (ce qui est normal : en général, il y a un petit surplus d’activité le dernier vendredi de la fenêtre d’intégration, mais la fin de semaine est plus calme) et j’ai décidé de ne pas tenir compte de tout ce qui pourra arriver demain, de fermer tout de suite la fenêtre d’intégration et de publier la RC-1.

Je m’attendais à ce que la version 4.3 soit plutôt petite après les gros changements apportés par la version 4.2, mais ce n’est pas vraiment le cas – sa taille est plutôt moyenne, en fait. En effet, tout paraît normal, avec des modifications réparties à 70 % pour les pilotes, 10 % pour les mises à jour des architectures et les 20 % restants éparpillés (systèmes de fichiers, réseau, outils, documentation, gestion de la mémoire et mises à jour du « cœur » du noyau, etc.).

Du côté des pilotes, les pilotes graphiques en constituent une grosse part, en partie à cause des mises à jour de Nouveau qui n’avaient pas pu être intégrés dans la 4.2, donc il y a là en fait une mise à jour qui en vaut deux. Mais il y a aussi des mises à jour de pilotes dans la plupart des autres sous‐systèmes : réseau (filaire et sans‐fil), recette (staging) [N. D. T. : branche de mise au point centralisée avant intégration à la branche principale], média, cryptographie, contrôleur de broches (pinctrl), pour n’en nommer que quelques‐unes.

Les mises à jour d’architectures sont pour moitié sur ARM (notamment les mises à jour de l’arborescence matérielle [devicetree]), avec l’autre moitié éparpillée (x86, MIP, ARM64, PowerPC, s390).

Du côté des systèmes de fichiers, le gros du changement (en lignes de code) est la suppression du système de fichiers ext3 (ext4 assurant encore la prise en charge du ext3 — mais le code spécifique à ext3 a disparu). Mais il y a aussi des mises à jour diverses un peu partout : F2FS, Btrfs, NFS, XFS, UFS, GFS2, proc…

Comme d’habitude, l’historique complet des changements est trop gros pour être publié, par conséquent je joins mon historique de fusion qui donne une idée des changements intégrés et de l’ensemble de la situation…

Allez‐y, testez,

Linus

RC-2

La version RC-2 est sortie le dimanche 20 septembre 2015 :

Nous revenons au calendrier dominical habituel, voici donc la RC-2. Comme c’est la tendance depuis un moment maintenant, la RC-2 est assez petite, probablement parce qu’il faut un bout de temps avant que les rapports de régression ne commencent à arriver peu à peu (et certaines personnes attendent probablement délibérément la RC-2 pour ne serait‐ce que commencer à tester — vous, vous êtes des trouillards).

Quoi qu’il en soit, tout semble plutôt normal. Il y a quelques perturbations un peu partout dans l’arborescence à cause du ménage effectué dans le gestionnaire de flux des interruptions [IRQ flow-handler] qui a enlevé le paramètre redondant de numéro d’interruption. Mais à part ce changement ponctuel, c’est plutôt calme et succinct — nous verrons si ça va continuer. Touchons du bois.

Sinon, c’est le mélange habituel de corrections d’architectures et de pilotes, avec une pincée d’autres choses (les mises à jour de l’outillage de performances sortent du lot, par exemple). Je n’ai rien vu de particulièrement alarmant et le résumé ci‐joint, donne tous les détails plutôt ennuyeux.

Donc, si quelqu’un n’a pas osé faire la mise à jour juste après la fin de la période d’intégration, qu’il se lance. On a besoin de gens pour tester et remonter les problèmes.

Linus

RC-3

La version RC-3 est sortie le dimanche 27 septembre 2015 :

Et comme d’habitude, la RC-3 est de fait plus grosse que la RC-2 (les corrections commencent à affluer), mais rien de particulièrement alarmant ne sort du lot.

Tout paraît normal : l’essentiel concerne les pilotes (un peu partout, mais les pilotes graphiques et le réseau sont les parties les plus importantes), ainsi que les mises à jour d’architectures. Il y a aussi des mises à jour du réseau et des systèmes de fichiers, accompagnés de documentation.

Allez la récupérer,

Linus

RC-4

La version RC-4 est sortie le dimanche 4 octobre 2015 :

Vous savez tous comment ça se passe maintenant. C’est dimanche, et il y a une nouvelle version candidate.

Tout semble plutôt normal. Nous avons notablement moins de modifications que dans la RC-3 (qui était particulièrement grosse) et je ne vois rien d’exceptionnellement alarmant.
Les statistiques semblent également tout à fait normales : un peu moins de la moitié des modifications concernent des pilotes (DRM continue à être notable, mais il y aussi InfiniBand, MMC, la couche d’entrées, etc.). À peu près un quart est constitué des mises à jour d’architectures (m68k, MIPS, x86) et le dernier quart est complètement varié (mise à jour de la documentation, outils, scripts, ordonnanceur, gestion de la mémoire…).

La liste des changements jointe donne une idée des détails.

Linus

RC-5

La version RC-5 est sortie le dimanche 11 octobre 2015 :

Le cycle de publication de la 4.3 se poursuit en douceur — touchons du bois. Il n’y a rien de particulièrement inquiétant ici : on a eu quelques retombées ennuyeuses provenant de la nouvelle fonction strscpy() (elle n’est pas encore réellement utilisée, mais on a eu des erreurs de compilation sur certaines architectures) et un changement dans la couche VFS qui a révélé un problème ancien et fascinant sur ext[3-4] ; mais dans l’ensemble, tout semble plutôt normal. C’est l’habituel « plein de petites corrections sur le code des pilotes et des architectures, saupoudrées de quelques mises à jour des systèmes de fichiers en guise de diversité ». Le résumé ci‐joint donne un aperçu des détails.

L’activité semble également se calmer gentiment, bien que, comme il n’y a pas eu de récupération de code réseau cette semaine, on pourrait bien en trouver un paquet dans la prochaine RC.

Quoi qu’il en soit, si vous n’avez pas testé un noyau récent dernièrement, n’hésitez pas à vous lancer dès maintenant — ça a l’air pas mal du tout.

Linus

RC-6

La version RC-6 est sortie le dimanche 18 octobre 2015 :

Cela continue à être calme, et même de plus en plus calme. J’en suis vraiment heureux, bien que ma nature suspicieuse cherche quelque chose à critiquer. Les gens se comportent‐ils de leur mieux en raison du Kernel Summit qui approche, tout le monde cherchant à se montrer sous son meilleur angle ?

Ou peut‐être est‐ce simplement l’une de ces rares et indolores versions où rien de mauvais n’arrive ?

Ce serait adorable.

Qu’importe la raison, il n’y a rien de bizarre ou d’effrayant en vue, et le journal résumé ci‐joint est agréable et court. La quasi-totalité concerne les pilotes, avec notamment les correctifs sur InfiniBand et les pilotes graphiques. Mais même là, le plus gros correctif (et de loin) consiste simplement en une clarification du message de copyright dans InfiniBand, qui à lui seul forme un tiers de l’ensemble du correctif. Car le reste est vraiment mineur.

En dehors des corrections de pilote, il y a quelques toutes petites mises à jour d’architectures (le plus gros étant quelques corrections de KVM sur x86 pour l’émulation SMM, mais même ces dernières ne sont en aucun cas énormes). Et une poignée de corrections d’une ligne concernant la gestion mémoire.

Autrement dit, tout a l’air vraiment bien. Touchons du bois.

Linus

RC-7

La version RC-7 est sortie le dimanche 25 octobre 2015 :

Il est possible qu’il soit encore samedi chez moi, mais grâce au Kernel Summit à venir en Corée, j’ai pris une longueur d’avance avec un fuseau horaire de +9 h, et ici c’est dimanche. Donc c’est le jour de la publication.

Cette RC casse la tendance de « réduction agréable et d’accalmie », principalement en raison au fait que nous avons intégré les corrections réseau en RC-7 (mais pas en RC-6). Il y a aussi quelques autres intégrations un peu plus grosses (corrections de systèmes monopuces ARM, pilotes graphiques, couche bloc et média) et évidemment toutes les corrections de pilotes divers, etc. Mais les changements réseau sont la raison pour laquelle cette RC a l’air quelque peu différente des précédentes.

Et malgré cette petite augmentation de taille, rien n’a l’air particulièrement inquiétant et ce cycle de publication continue à se dérouler en douceur. Comme déjà évoqué auparavant, la semaine prochaine est celle du Kernel Summit et, avec un grand nombre de mainteneurs principaux occupés à Séoul, je présume que les choses resteront calmes et, à moins que quelque chose de bizarre ne survienne, je sortirai la 4.3 finale dimanche prochain (d’ici là, je serai de retour dans mon fuseau horaire habituel).

Le journal résumé ci‐joint est disponible pour les gens qui veulent inspecter les détails.

Linus

Version finale

La version finale est sortie le dimanche 1^er novembre 2015 :

Alors, la dernière semaine de la série des RC semblait chargée au point que je commençais à m’inquiéter pour la publication finale. Mais, les chiffres montrent qu’en réalité il ne s’agissait que d’une impression subjective de ma part, probablement due au Kernel Summit et au voyage de retour de la Corée à chez moi. Ce n’était pas vraiment une semaine particulièrement chargée, c’est juste que les demandes d’intégration ont été plus importantes dans les tout derniers jours.

On a eu une mise à jour du code réseau et une correction tardive pour un bogue du mode vm86 sur x86 introduit par les nettoyages de vm86, mais à part ça c’est juste un ensemble de petites corrections d’une ligne un peu partout. OK, le truc sur le mode vm86 était également une correction d’une ligne, mais il s’agissait d’une chose un peu plus angoissante, car ça avait l’air plus effrayant que ça ne l’était en réalité, jusqu’à ce que quelqu’un (Andy) comprenne ce qu’il se passait.

Les changements depuis la RC-7 sont dominés par les trucs réseau, mais comme vous pouvez le voir sur le journal résumé ci‐joint, il n’y a rien de particulièrement inquiétant.

Donc, dans l’ensemble, ça reste un cycle de publication assez calme jusqu’à la fin. Et avec la sortie de la 4.3, la fenêtre d’intégration pour la 4.4 est évidemment ouverte, et gardons les doigts croisés pour que ce soit une publication tout aussi tranquille. Tout spécialement depuis que Greg a décidé, par anticipation (c’est une expérience amenée par une discussion lors du Kernel Summit) que la 4.4 serait une autre version LTS [N. D. T. : Long Term Support — maintenance à durée étendue].

Linus

Les nouveautés

Architecture

Plusieurs améliorations ont permis de diminuer le temps de démarrage du noyau sur système x86.

Len Brown, d’Intel, continue à travailler sur l’optimisation du démarrage sur x86. Son travail porte principalement sur quatre correctifs [plus de détails sur Phoronix.com].
Nous avons ainsi un gain de 700 µs sur trois correctifs et un peu d’élimination de code mort.

Une meilleure analyse de performance sur certains processeurs

perf est un outil déjà très puissant pour l’étude des performances sous Linux. Avec certains processeurs Intel, cette analyse pourra désormais être encore plus précise grâce à la récupération d’informations par perf directement sur la puce avec le processor trace (PT). Parmi les promesses de ce matériel, on a notamment un meilleur suivi des applications avec plusieurs fils d’exécution (threads).

C’est bien entendu des développeurs d’Intel qui ont proposé l’ajout des modifications en plusieurs parties. On a ainsi dans le détail un décodeur pour PT, le code pour gérer le PT, l’ajout du nécessaire dans perf, un script d’exemple de suivi de performance de PostgreSQL.

Prise en charge ARMv8.1

Linux 4.3 prend désormais en charge l’architecture ARMv8.1 (disponible avec le Tegra X1, par exemple). Cette dernière est une mise à jour mineure de la spécification ARMv8, qui apporte principalement la prise en charge des processeurs 64 bits dans le monde ARM. Les nouveautés implémentées pour ARMv8.1 sont le PAN, le LSE et la prise en charge de DBM.
Le PAN est un acronyme en anglais pour Privileged Access Never — aucun accès privilégié — et représente la solution ARM pour empêcher les déréférencements dans le noyau.
LSE, Large System Extension — extension système large — est utilisé pour construire des verrous et des opérations atomiques utilisables à grande échelle.
Enfin, DBM — Dirty Bit Management — est le système de gestion du bit « sale » qui sert principalement à la mise à jour propre et automatique des entrées dans la table des pages de la mémoire virtuelle paginée (PTE).

[Article de CNXSoft : Linux 4.3 Release — Main Changes, ARM and MIPS Architectures]

Amélioration de la prise en charge des systèmes monopuces ARM

• Nouvelle prise en charge des systèmes monopuces 64 bits ARM suivants :

  1. Broadcom North Star 2 (pas encore disponible) ;
  2. Marvell Berlin4CT (pas encore disponible) ;
  3. Mediatek MT6795 (la réponse de Mediatek au SnapDragon 810 et sa volonté de venir sur le marché du haut de gamme) ;
  4. Rockchip RK3368 disponible par exemple ici. C’est sans doute la carte ARM 64 bits la moins chère du marché.

• Plus de 23 000 lignes de code pour l’arborescence matérielle DeviceTree. Cela permet de prendre en charge dans le noyau principal les Chromebooks Rockchip, la carte d’évaluation i.MX6UL, les modules Gumstix Overo et le matériel UniPhier.

• Nouveaux pilotes Qualcomm SMM/SMD pour communiquer avec les coprocesseurs de certaines plates‐formes, ainsi que des ajouts pour Tegra (Tegra X1 et Denver).

MIPS n’est pas mort

Ajout de la prise en charge du processeur 64 bits MIPS I6400 et amélioration de la prise en charge des Octeon Cavium CN68xx.

s390

Ajout intéressant, la prise en charge de la NUMA (architecture mémoire non unifiée, introduite par AMD dans son architecture Bulldozer) pour s390. Enfin, la prise en charge d’une fausse NUMA, ou une NUMA purement logicielle, pour distribuer la mémoire sur les différents processeurs. Il semblerait que sous certaines circonstances, cela améliore les performances du système, et/ou sa latence.

AMD Carrizo

Linux 4.3 rend désormais disponibles, via le sous‐système hwmon, les informations énergétiques communiquées par les processeurs de la génération Carrizo d’AMD (les APU A10 par exemple).

IPC

KDBUS a reçu de nombreuses modifications. Il était déjà utilisé dans Fedora Rawhide (la branche instable) depuis le 30 juillet, mais a été retiré récemment. Certains aspects de KDBUS pourraient être repensés, ce qui signifie que l’intégration officielle de KBDUS dans Linux a peu de chances d’avoir lieu pendant le cycle de la version 4.4.

Pour rappel, l’intégration de KDBUS avait été proposée pour Linux 4.1 et a été reportée durant le cycle de la 4.2.

Développement

• Introduction d’une nouvelle structure logicielle (framework) pour les pilotes de périphériques à mémoire non volatile qui devrait être utilisée lors de la sortie de la technologie Intel 3D XPoint. La documentation de NVmem (pour Non Volatile memory layer) est disponible sur le site kernel.org.
• L’appel système membarrier() a enfin été intégré. C’est un correctif qui est en gestation depuis au moins 2010. Il permet de forcer la synchronisation entre processeurs, mais uniquement sur les processeurs qui font fonctionner l’application qui requiert cette synchronisation. Consultez l’article de LWN.net, en anglais, pour plus de détails.
• La gestion des erreurs d’entrées‐sorties bloquantes a été simplifiée. Il y a désormais un nouveau champ bi_error dans la structure bio qui sert à stocker un code d’erreur. L’utilisation de bi_end_ui() a été supprimée.
• Changement dans l’interface static-key, qui provoquait des confusions de nommage.
• Le module de signature utilise désormais PKCS#7, ce qui nécessite d’avoir openssl-devel disponible pour construire le noyau avec ce module.

Pilotes graphiques libres

Direct Rendering Manager

Rien de bien intéressant dans le code commun des pilotes graphiques libres, si ce n’est des corrections de bogues dans la partie liée à la gestion atomique du mode graphique. Plusieurs nouveaux contrôleurs d’affichage sont maintenant gérés par Linux.

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

AMD/ATI

Pilote de rendu nouvelle génération (pilote amdgpu)

Les cartes graphiques haut de gamme AMD R9 Fiji sont maintenant partiellement gérées par Linux. Cette famille a été commercialisée dès la fin du mois de juin 2015.

Autre nouveauté, l’ajout d’un ordonnanceur pour le processeur graphique. Son rôle est de répartir de manière plus juste les ressources de calcul du processeur graphique, mais aussi de donner la priorité aux applications les plus importantes. C’est notamment le cas du compositeur qui utilise le processeur graphique pour composer l’image à l’écran. Il a besoin de produire de façon prédictible la prochaine image avant la synchronisation verticale de l’écran, sous peine d’avoir à jeter les images qui ont été calculées, mais jamais affichées.

Pour plus d’informations, vous pouvez consulter les demandes d’intégration.

Pilote HSA (pilote amdkfd)

AMD ajoute la gestion des processeurs à unité graphique intégrée (APU) Carrizo, sortis en juin 2015, au pilote amdkfd, qui permet de faire communiquer plus rapidement le processeur graphique et le processeur central.

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

Intel (pilote i915)

L’unité graphique des processeurs Intel Skylake Gen9 est maintenant gérée par défaut et ne nécessite plus de passer d’argument au noyau.

Les autres nouveautés sont plus cachées, mais restent importantes. La plus notable est la gestion du mode graphique classique qui utilise maintenant le code de la gestion atomique, ce qui permet de tester ces parties de code un peu plus avant qu’elles puissent être activées par défaut.

Toujours du côté de l’affichage, la gestion des profondeurs de couleur de 12 bits par composante est maintenant disponible et activée par défaut pour le HDMI et les écrans compatibles.

Du côté de la gestion d’énergie, la fréquence de l’horloge du contrôleur d’affichage est maintenant dynamique, ce qui permet d’économiser de l’énergie lorsque des écrans à basse ou haute résolution (non 4K) sont présents. La gestion de la compression du tampon de trame (framebuffer), ainsi que la gestion du mode d’auto‐rafraîchissement de l’écran avancent encore, mais restent désactivées par défaut, car elles provoquent des blocages de l’écran sur certains systèmes.

Le code de suivi des requêtes, qui permet de savoir si une tâche soumise de façon asynchrone au processeur graphique a été exécutée ou pas encore, a été revu afin de prendre en charge la synchronisation entre plusieurs processeurs graphiques, mais également pour la venue éventuelle d’un ordonnanceur (voir la partie AMD). Ce travail n’est cependant pas encore terminé, la suite dans la prochaine dépêche noyau !

Pour plus d’informations, vous pouvez consulter l’article de blog du mainteneur i915.

Matrox (pilote mgag200)

Le pilote Matrox, qui n’avait pas reçu de modification depuis deux ans, vient de bénéficier de la gestion d’une nouvelle famille de processeurs graphiques, ainsi qu’une variante dans la famille précédente.

Pour plus d’informations, vous pouvez consulter les deux commits.

NVIDIA (pilote nouveau)

Nouveau n’avait pas reçu de changement dans Linux 4.2, car un gros changement était en cours. Il fait son entrée dans Linux 4.3 et modifie la façon dont les différents modules sont initialisés et utilisés, afin que le compilateur puisse plus facilement détecter des erreurs d’accès. Le code qui en résulte est, de plus, bien plus simple à lire et modifier.

Ben Skeggs en a également profité pour revoir l’interface NVIF. Cette dernière a pour but d’exposer à l’espace utilisateur ou à des machines virtuelles les objets internes à Nouveau. Cette interface n’a encore jamais été utilisée. Ce changement n’est donc pas problématique.

NVIDIA, par le biais d’Alexandre Courbot, a ajouté le code de gestion préliminaire pour les processeurs Tegra basés sur l’architecture Maxwell (GM20B). Cette gestion est cependant inutilisable, car elle requiert un microcode signé par NVIDIA qui n’a pas encore été rendu public. Ce processeur est maintenant facilement accessible aux passionnés grâce à la carte de développement Jetson TX1.

Samuel Pitoiset a retravaillé le code de configuration et lecture des compteurs de performance globaux avant d’ajouter la gestion des compteurs qu’il a effectuée en rétro‐ingénierie pour les familles NV50 et NVC0. Pour l’instant, peu de signaux sont reconnus pour la famille NVC0, mais le travail de rétro-ingénierie devrait reprendre, quand l’infrastructure au complet sera en place. À cette fin, il manque une bibliothèque en espace utilisateur pour accéder à l’interface NVIF introduite dans Linux 3.17 pour Nouveau et modifiée dans Linux 4.3. Il restera ensuite à modifier Mesa 3D pour exposer ces compteurs via l’interface OpenGL GL_AMD_performance_monitor et l’afficheur tête haute de Gallium3D GALLIUM_HUD. Ces modifications sont le fruit d’un travail de longue haleine de la part de Samuel. Il a commencé à travailler sur ce sujet lors du Google Summer of Code 2013. Une page détaillant l’état d’avancement de l’implémentation de la gestion des compteurs de performance est en cours de construction.

Roy Spliet a ajouté la gestion du recadencement manuel pour les cartes NVA0 et l’a activée par défaut.

Pour plus d’informations, vous pouvez consulter la présentation récapitulative de l’état du pilote faite au XDC2015 par Alexandre Courbot (NVIDIA) et Martin Peres (hobbyiste) ou sa transcription faite par LWN.net.

VMware (pilote vmwgfx)

Le pilote vmwgfx de VMware a reçu d’importantes modifications ayant pour but de pouvoir exposer OpenGL 3.3 dans les machines virtuelles.

Les modifications apportées sont l’utilisation d’une nouvelle interface de programmation pour la gestion des tampons de trame (frame buffer), un nouveau mécanisme d’envoi de commandes qui remplace l’ancien tampon circulaire et la gestion d’un nouveau périphérique virtuel appelé DX qui permet d’obtenir la gestion d’OpenGL 3.3.

Les modifications apportées à Mesa 3D (pilote 3D en espace utilisateur) nécessaires pour atteindre OpenGL 3.3 sont actuellement disponibles dans la branche de développement de Mesa 3D et devraient être disponibles prochainement, dans Mesa 3D 11.1.

Pour plus d’informations, vous pouvez consulter la demande d’intégration vmwgfx, ainsi que le courriel d’annonce de la fonctionnalité.

Pilotes graphiques pour systèmes monopuces

Qualcomm Snapdragon (pilote msm)

• prise en charge des cartes de développement DragonBoard 410c (les puces ADV7533 nécessitant encore du travail) ;
• prise en charge initiale des MSM8x94 (Snapdragon 810) ;
• prise en charge des MSM8x74v1 (ajoutée à celle de la v2 existante) ;
• prise en charge des plans DMA sur les MDP5 (plans additionnels ne pouvant pas être rééchelonnés) ;
• ajout de nouveaux formats d’espace colorimétrique YUV aux MDP5 (simple plan VYUY, UYVY, YUYV et YVYU ; double plan NV16 et NV61 ; et triple plan YUV420 et YVU420) ;
• prise en charge de la rotation pour les MDP5 ;
• prise en charge initiale de la protection anticopie HDCP ;
• corrections diverses, etc.

Freescale

Nouveau pilote fsl-dcu prenant en charge la gestion des modes d’affichage du DCU (Display Controller Unit) des systèmes monopuces de Freescale.

Réseau

Prise en charge initiale des VRF

Derrière l’idée des VRF, ou Virtual Routing and Forwarding, se cache le fait d’avoir plusieurs tables de routage, afin de se comporter différemment selon l’environnement. Le premier exemple est un équipement en production dont on planifie des changements dans son routage. Grâce aux VRF, l’administrateur pourra conserver la configuration actuelle dans une table et préparer la table à déployer dans un autre VRF. Un autre exemple serait une application spécifique qui doit utiliser une règle de routage différente.

Cette fonctionnalité s’insère de façon peu intrusive pour qui veut l’utiliser. En effet, il y a déjà des fonctionnalités avancées de routage dans le noyau (notamment configurables avec ip rule), qui permettent de faire du routage en fonction de l’adresse IP source, d’un marquage du pare‐feu, etc. Et pour les applications, on peut utiliser l’option SO_BINDTODEVICE (ping -I par exemple) pour choisir l’interface. On a déjà presque tout : il faut juste lier le domaine de routage (la VRF) à une interface virtuelle (et donc la créer) et gérer les quelques détails (l’isolation ARP entre les différents domaines notamment).

C’est ce que propose cette demande de changement. À noter que la fonctionnalité n’est pas encore complètement terminée, on ne peut notamment pas utiliser de VRF en IPv6.

IPv6

Compilation par défaut dans le noyau

C’est une nouveauté qui n’est pas passée inaperçue, le code pour IPv6 est désormais compilé par défaut dans l’image du noyau (la compilation en module était auparavant le mode par défaut). Il s’agit avant tout d’une décision symbolique, la plupart des grandes distributions ayant déjà configuré leurs noyaux ainsi.

Les détails, dans la demande de modification.

Ajout des Identifier Locator Addressing à IPv6 — le retour de la dualité des IP

Les Identifier Locator Addressing (ILA) sont une nouvelle méthode pour tenter de résoudre un bon vieux problème des protocoles IP : une adresse IP est utilisée actuellement à la fois comme identifiant d’équipement et comme information de localisation.
Pour le premier cas, vous pouvez ainsi penser à l’utilisation des adresses IP source et destination, pour relier (en complément des numéros de ports) un paquet à une socket TCP.
Pour le second cas, on parle du routage : l’adresse est lue par les routeurs et permet d’envoyer le paquet au bon endroit.
Le premier problème évident avec cette architecture est la mobilité. L’équipement (et on espère donc son identifiant) ne change pas, mais sa localisation si. Un autre souci est le multi‐homing, c’est‐à‐dire avoir plusieurs fournisseurs d’accès pour un équipement. L’équipement aura plusieurs adresses IP, mais on aimerait qu’il puisse être identifié de façon identique avec les deux.

Cette dualité de l’adresse IP est bien documentée, par exemple dans la RFC 4984, et en français sur le blog de Stéphane Bortzmeyer. Il y a même des protocoles, comme LISP, qui devraient permettre d’y remédier s’ils sont déployés.

Les ILA qui nous intéressent ici visent un cas d’utilisation bien précis : les machines virtuelles et les services construits pour pouvoir être migrés entre différents serveurs physiques (et donc changer de localisation). La principale motivation de ce travail est le rejet de l’existant, notamment la volonté d’avoir un protocole sans encapsulation (ce que fait LISP) ni en‐têtes supplémentaires dans le paquet IP. Le paquet sera ainsi pleinement traitable par un équipement intermédiaire standard (routeur, pare‐feu…) sans aucune mise à jour. L’encapsulation étant coûteuse en ressource, cette motivation est très compréhensible.

Rentrons dans le concret : l’idée est de prendre le format d’une adresse IPv6 standard et de la couper en deux. La première partie sera la localisation (lue par le routage jusqu’à joindre la machine physique du service), la seconde partie servira d’identification (sans aucun lien avec une interface physique). Une application n’a besoin que de la seconde partie, la première moitié sera ajoutée par le noyau lors de l’émission du paquet (qui lui aura l’information de la localisation réelle du service). Pour des questions de compatibilité, les applications rempliront en réalité la première partie avec les informations qu’elles possèdent (exemple : le résultat d’une requête DNS) et le noyau se chargera de récrire les 64 premiers bits (la partie de localisation). C’est le mécanisme de réécriture d’adresse connu habituellement sous le nom de NAT, mais utilisé en local.

La configuration de tout ça se fait actuellement à l’aide de la commande ip, en rajoutant des liens (mapping) statiques entre l’identifiant et sa localisation. Si vous voulez quelque chose de vraiment dynamique, il manque donc la partie en espace utilisateur pour mettre à jour les localisations des services.

Au niveau de la sécurité, c’est léger, mais documenté par l’auteur. L’absence d’en‐tête supplémentaire empêche également l’ajout d’information pour assurer à l’application que le destinataire qu’il croit contacter à l’aide de l’identifiant est bien l’équipement réellement contacté. Cette technologie ne devra être utilisée que sur des réseaux bien maîtrisés, ce qui permet la simplicité du mécanisme pour un problème aussi complexe.

Pour plus d’informations, il y a tout d’abord la demande de changement, qui détaille notamment la (faible) dégradation de performance. Il y a également un article sur LWN.net et un draft à l’IETF (écrit par l’auteur du code du noyau Linux. Vous pouvez également constater son changement d’employeur entre la v0 et la v1 du draft).

Suivi des connexions Open vSwitch

Quand vous avez de nombreuses machines virtuelles, réparties ou non sur différents hyperviseurs, vous avez probablement également envie de virtualiser la commutation des paquets (switching) entre les différentes machines virtuelles, afin qu’il soit transparent de migrer des services et d’avoir de bonnes performances.

Sous Linux, Open vSwitch est une solution pour remplir ce rôle. Et dans ce nouveau noyau, un utilisateur peut désormais suivre l’état des connexions Open vSwitch.

Performances

De la qualité de service plus rapide

Que serait un nouveau noyau sans des optimisations de performance en réseau ? Pour cette version, on peut citer des changements pour tc (traffic control), qui permet de gérer la qualité de service (limiter un utilisateur à un débit, rendre prioritaire certains usages, etc.). Dans la demande de changement, l’auteur parle d’un passage sur son environnement de 5 millions de paquets traités par seconde à 11 millions désormais.

Tunnels légers

Malgré les dégradations de performance de l’encapsulation réseau, qui ont été une des motivations du concept des ILA décrites précédemment, encapsuler et décapsuler des paquets est une opération très courante dans les réseaux IP. Pour le grand public, l’une des opérations classiques est notamment d’utiliser un réseau privé virtuel (VPN pour les intimes). Pour les centres de données, Open vSwitch (OVS) fait également de l’encapsulation.

Améliorer les performances et avoir une approche un peu unifiée pour l’encapsulation présente donc un avantage et une demande de changement dans ce sens a été proposée. A priori, cette approche devrait permettre d’obtenir de meilleures performances et de mieux passer à l’échelle. Les encapsulations pour OVS et MPLS (très récemment introduit en version 4.1 du noyau) utilisent déjà cette nouvelle interface.

Si vous avez du mal à être convaincu que ce changement est important, vous pouvez lire le début du courriel résumant les changements réseau de ce noyau.

Nouveau pilote

Si les performances dans le noyau sont essentielles, certains fabricants produisent du matériel capable de très fortement diminuer la tâche du noyau en effectuant de très nombreuses opérations directement dans le matériel. Le processeur SwitchX-2 entre dans cette catégorie et peut désormais être utilisé avec Linux grâce aux changements [1, 2 et 3]. Avec ce matériel, il devient en théorie possible de construire de gros commutateurs (switchs) performants avec un noyau Linux. Il a suffi d’adapter le code pour ne pas commuter en logiciel un paquet déjà commuté par la carte.

Un peu d’humain

Si cette nouvelle version est riche en améliorations réseau, l’ambiance sur la liste de diffusion n’a pas toujours été au beau fixe. Linus Torvalds a notamment réagi à la demande d’intégration de la partie réseau par un :

« Christ, people. Learn C, instead of just stringing random characters together until it compiles (with warnings). »

Que l’on pourrait traduire par :

Bon dieu, les gars. Apprenez le C, au lieu d’enchaîner des caractères au hasard jusqu’à ce que ça compile (avec des alertes).

Vous pouvez retrouver le courriel complet dans les archives de la liste.
Cet incident, bien que postérieur à ce qui va suivre, est peut‐être à rapprocher avec l’annonce du départ de la développeuse qui maintenait les pilotes USB3, qui critique notamment le manque de respect sur les différentes listes de diffusion du noyau.

Sécurité

Anti‐fork‐bomb

Un mécanisme anti‐fork‐bomb a été ajouté au noyau. Il se base sur un ajout récent du noyau, les cgroups_pid. Ce correctif introduit une nouvelle option, fork_remaining. Cette valeur est décrémentée à chaque appel système fork(). Lorsqu’elle atteint zéro, le noyau refuse les forks supplémentaires. La valeur unlimited permet de désactiver cette limite.

Un petit exemple :

mkdir /sys/fs/cgroup/pids/parent
echo 2 > /sys/fs/cgroup/pids/parent/pids.fork_remaining
echo $$ > /sys/fs/cgroup/pids/parent/cgroup.procs
cat /sys/fs/cgroup/pids/parent/pids.fork_remaining
1
cat /sys/fs/cgroup/pids/parent/pids.fork_remaining
0
cat /sys/fs/cgroup/pids/parent/pids.fork_remaining
sh: fork: Resource temporary unavailable

Révision de l’héritage des capabilities

Les capacités (capabilities) sont une extension de la gestion des droits d’un programme permettant d’effectuer des tâches habituellement réservées au super‐utilisateur root (ou un programme marqué setuid). Ces capacités peuvent être ajoutées au niveau d’une tâche en cours (grâce à CAP_SETPCAP) ou bien au niveau d’un fichier (vous pouvez essayer getcap /bin/ping, par exemple).

Toucher aux capacités est toujours un problème difficile, la moindre modification risquant de se transformer en faille de sécurité. L’héritage de ses capacités, permettant à un programme de déléguer ses pouvoirs spéciaux à une sous‐tâche, est notamment très discuté.

L’argumentation de Andy Lutomirski, développeur du noyau, est que l’héritage proposé actuellement est, justement, totalement inutile si vous n’êtes pas root. Pour le faire fonctionner correctement, il faut marquer manuellement chaque fichier concerné. Dans la vraie vie, personne ne le fait, car c’est proche d’un travail d’Hercule et qu’en plus de nombreux systèmes de fichiers ne le permettent pas.

Il propose donc l’ajout d’un masque d’environnement, simplifiant l’héritage et le rendant fonctionnel. Si vous voulez les détails de la complexité du problème et de l’implémentation, vous pouvez lire la demande de changement.

Systèmes de fichiers

Les changements dans les systèmes de fichiers pour cette version sont majoritairement constitués de corrections et de nettoyages.

Btrfs

Btrfs reçoit une correction du trim pour quelques cas particuliers où les trims étaient manquants. Il reçoit également des corrections pour RAID 5 et RAID 6, en particulier pour le nettoyage de données et le remplacement de périphériques quand plusieurs sont manquants. Les nouveautés concernent aussi la prise en charge de nouveaux contrôleurs blkio pour un seul périphérique (gestion de plusieurs périphériques prévue), ainsi que des corrections et nettoyages divers.

Pour plus d’informations, vous pouvez consulter la [demande de modification].

ext3

Le code concernant ext3 a été supprimé. Désormais, les systèmes de fichiers ext3 devront être montés avec le mode de compatibilité d’ext4. Dans la pratique, cela fait plusieurs années que de nombreuses distributions le font déjà, ce qui a servi à montrer que le code d’ext4 était assez stable pour remplacer celui d’ext3.

Si le changement n’affectera pas l’espace utilisateur, cela permet de supprimer 28 000 lignes de code et de supprimer des contournements spécifiques à ext3 dans la mémoire virtuelle du noyau et les couches bloc. D’autre part, cela simplifie la maintenance, car il fallait vérifier à chaque fois si une correction de bogue dans ext4 concernait ext3 pour être manuellement portée.

[source : LKML]

Le système de fichiers ext2 n’a pas été supprimé car, d’après Theodore Ts’o :

C’est un système de fichiers simple qui permet de comprendre facilement ce qui est nécessaire pour créer un nouveau système de fichiers.

ext4

Comme d’habitude, il y a principalement des corrections de bogues, en particulier sur les quelques ajouts et modifications apportés à Linux 4.2 (voir les détails sur LKML).

[source : Phoronix.com]

F2FS

F2FS est un système de fichiers adapté aux SSD et autres supports de stockage Flash. Pour cette version de noyau, nous n’avons pas de nouveauté importante, mais pas mal de petits changements, comme l’amélioration et la correction des extent_caches, qui est maintenant une option de montage par défaut.

Un travail non négligeable a été également mené pour éviter des problèmes de performance dus à la mémoire (limiter les requêtes de pages mémoire).

De plus, un nouvel appel ioctl() a été ajouté, ioctl(F2FS_GARBAGE_COLLECT), qui permet à l’utilisateur de faire explicitement une requête de nettoyage des tâches en cours.

XFS

• gestion des cycles de vie d’EFI/EFD retravaillée pour corriger des corruptions de journaux de récupération, des plantages et des attentes lors de démontage ;
• métadonnées UUID séparées sur le disque afin d’activer le changement de l’étiquette d’amorçage UUID pour les systèmes de fichiers en version 5 ;
• correction de mauvaises compilations de gcc pour certaines plates‐formes et certains niveaux d’optimisation ;
• correction de l’allocation d’attributs distante et de la récupération de données corrompues ;
• correction des annotations des vérificateurs de verrous (lockdeps) des nœuds d’index (inodes) générant des erreurs avec de trop nombreuses sous‐classes ;
• modifications du verrouillage des nœuds d’index (inodes) de répertoires afin d’éviter que les vérificateurs de verrous lockdeps ne génèrent de faux positifs ;
• une poignée de corrections de corruptions mineures ;
• divers autres petits nettoyages et corrections.

Pour plus d’informations, vous pouvez consulter la demande de modification.

Virtualisation

KVM

Comme d’habitude, les correctifs sont arrivés en deux lots, le premier avant les vacances de Paolo Bonzini (mainteneur KVM) et le deuxième au retour de ses vacances. Il n’y a quasiment que des corrections de bogues et peu de nouveautés :

• ARM : prise en charge complète du débogage sur ARM64, changement d’état actif pour les interruptions de l’horloge, sauvegarde et restauration fainéante pour les registres de calcul flottant et SIMD pour ARM64, une cible générique ARMv8 (pour ne pas avoir à cibler un processeur particulier) ;
• PowerPC : activation du microthreading pour POWER8 ;
• x86 : prise en charge du MSR (Memory Service Routine) Hyper-V (l’hyperviseur de Windows) pour stocker les informations en cas de plantage.

Xen

Peu de nouveautés de même de ce côté (pourtant personne n’a annoncé de vacances) :

• conversion du pilote xen-blkfront à l’API multiqueue ;
• prise en charge des invités paravirtualisés de plus de 512 Gio sur x86 (cette fonctionnalité est cependant désactivée par défaut, car ils ne peuvent pas être migrés avec les outils actuels) ;
• toujours sur x86, prise en charge du PMU (outils d’analyse de performance utilisant perf) sur le domaine principal dom0 ;
• sur ARM, prise en charge de l’attachement de canaux de communication d’événements à plusieurs processeurs virtuels.

Le bilan en chiffres

Appel à volontaires

Cette dépêche a nécessité plus de 790 éditions (à l’heure de l’écriture de ces statistiques) et a mobilisé 19 personnes du 14 septembre au 29 novembre dans l’espace de rédaction.

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

	Mainteneur	Contributeur(s)
La phase de test	aucun	aucun
Arch	Romain Perier	Tiwaz, Florent Fourcot
IPC	aucun	ariasuni
Développement	aucun	Tiwaz
Pilotes graphiques libres	Martin Peres	aucun
Réseau	aucun	Florent Fourcot, Tiwaz
Systèmes de fichiers	aucun	ariasuni, Tiwaz
Sécurité	aucun	Florent Fourcot, Tiwaz
Virtualisation	Xavier Claude	aucun
Édition générale	aucun	jcr83, Davy Defaud, eggman, Moul

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, Réseau, Développement et IPC, 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. Essayons d’augmenter la couverture sur les modifications du noyau !
C’est un travail à faire au fil du temps, par ajouts successifs (une simple adresse URL ou un paragraphe enrichissent déjà le contenu et les sources), n’hésitez pas !

Aller plus loin

• Dépêches des noyaux précédents (338 clics)
• Site officiel du noyau Linux (281 clics)
• Die Neuerungen von Linux 4.3 (124 clics)