Sortie du noyau Linux 3.6

La sortie de la version stable 3.6 du noyau Linux vient d’être annoncée 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 est dans la seconde partie de la dépêche (qui est sous licence CC BY-SA).

NdA : Merci aux contributeurs ayant participé sur l’espace de rédaction : Sébastien Koechlin, Philip Marlowe, stiffux, M, detail_pratique, samo, baud123, Patrice Genieys, warwick, Olivier Esver, trois_1, Batchyx, ymorin, Grégoire Seux, Benoît, voondo, maboiteaspam.

Sommaire

• La phase de test
  • RC-1
  • RC-2
  • RC-3
  • RC-4
  • RC-5
  • RC-6
  • RC-7
• Les nouveautés
  • Veille et hibernation combinée
  • Améliorations de TCP
  • Suppression du cache de routage IPv4
  • Améliorations Btrfs
  • Améliorations dans la gestion de l’entropie
  • Pilotes graphiques
  • ext4
  • Gestion de l’énergie sur ATA et PCIe
  • Restriction sur la création de liens
• En vrac
• Statistiques

La phase de test

RC-1

La version RC-1 a été annoncée par Linus le 3 août 2012 :

Et encore une presque-deux-semaines-mais-pas-tout-à-fait phase d’intégration…
Eh oui, cela fait à présent juste un peu plus de 12 jours que la version 3.5 est sortie, et comme je déteste les gens qui m’envoient des demandes d’incorporation à la dernière minute, j’apprécie de leur couper l’herbe sous les pieds alors qu’ils pensaient faire leur demande la veille du quatorzième jour. Si c’était bien ça que vous aviez en tête, dommage pour vous.
Mais peut‐être plus important, cette fois j’ai des voyages prévus, et j’avais le choix entre laisser la fenêtre d’intégration pendant les 14  ours prévus et sortir la version -rc1 depuis l’aéroport (Wi‐Fi gratuit à PDX ! ), ou simplement la clore en avance et ainsi avoir un jour et demi de plus pour, éventuellement, peaufiner les détails avant de partir. J’ai évidemment choisi la seconde option.
J’ai essayé de prévenir à temps les gens qui avaient bien travaillé et avaient beaucoup de choses en attente dans linux-next : ce n’est donc pas une grosse surprise pour certains d’entre vous. Et je ne pense pas que j’ai vraiment loupé de grosses intégrations : si vous regardez le nombre de commits, cette -rc1 est un tout petit peu plus petite que celles des deux précédentes fenêtres d’intégration, mais c’était l’état de linux-next à ce moment. Je pense que c’est un effet « été », même si nous ne parlons que d’une différence de 10 %.

Bon, à propos des trucs intégrés ; comme d’habitude, même le résumé est trop gros pour être publié, cependant il y a la répartition habituelle : environ deux tiers des changements sont dans les pilotes — avec le pilote CSR issu de la branche staging qui est un gros morceau (mon Dieu que ce truc est gros et verbeux, même après la « merdectomie » [NdT : crapectomy]).
Sur la partie non-pilote, un petit peu plus du tiers est de l’architecture (ARM, x86, Tile, MIPS, PowerPC, M68k) et le reste est un partage équilibré parmi les systèmes de fichiers, les changements des includes, le réseau et « le reste ».

J’ajoute ci‐dessous mon « merge shortlog » perso, mais j’aimerais préciser que les personnes listées sont les personnes desquelles j’ai reçu la demande d’incorporation, ce qui n’est pas la paternité, mais seulement la personne à partir de laquelle j’ai reçu le code. Je remarque aussi que mon script shell pour générer cela a loupé des choses comme mon intégration du « patch-bomb » d’Andrew, parce qu’ils diffèrent des fusions git normales. Mais peut‐être que cela donne quand même une espèce d’aperçu des choses qui ont été ajoutées ou mises à jour.

RC-2

C’est le 16 août 2012 que Linus a annoncé la version RC-2 du noyau 3.6 :

Bon, à cause de mes voyages, la version -rc2 est sortie après deux semaines au lieu d’une. Mais elle est là maintenant.
Aussi, et pour la même raison, j’ai ignoré, de manière plutôt agressive, les demandes d’intégration qui semblaient déraisonnablement grosses et effrayantes et qui me faisaient dire « Hmm, cela aurait dû être prêt pour la fenêtre d’inclusion ». Donc, si vous m’avez envoyé une demande d’intégration et qu’elle n’a pas été incluse, demandez‐vous si elle avait l’air grosse et compliquée. Vous pouvez essayer de me la re‐soumettre, mais je vous suggère d’avoir de vraiment bonnes explications quant à pourquoi cela devrait être inclus en dehors de la fenêtre, si ce ne sont pas clairement juste des corrections critiques. Et si ce sont vraiment juste des corrections critiques, mais qu’elles sont malgré tout grosses, dites‐le, et expliquez pourquoi.

Cela dit, ce n’est pas si mal que ça. Oui, j’ai ignoré quelques demandes d’intégration, mais je dois dire qu’il n’y en avait pas tant que ça et le reste était plutôt calme. D’accord, il y a plus de 330 commits, mais sachant que c’est sur deux semaines, c’est un nombre auquel il fallait s’attendre (c’est même un peu faible) pour une des premières -rc. Oui, pour la version 3.5, la -rc2 était beaucoup plus petite, mais c’était inhabituel.

Les statistiques de diffs sont plutôt plates, si ce n’est la partie tcm_vhost (qui était en attente depuis la fenêtre d’inclusion). C’est aussi plutôt bon signe (même si c’est également un signe de mon strict principe « non, je n’inclurai pas ça en dehors de la fenêtre d’inclusion »). De toute façon, des statistiques calmes signifient qu’il n’y a eu nulle part de gros changements, juste quelques petites corrections un peu partout. Les changements les plus remarquables (encore une fois, à l’exception de tcm_vhost) sont les mises à jour de gpu/drm, ainsi que les mises à jour de tools/perf. Sinon, ce ne sont que de petits changements un peu partout.

RC-3

La version RC-3 a été annoncée par Linus le 22 août 2012 :

Une sortie de -rc en milieu de semaine pour coller avec la sortie en milieu de semaine de la version rc2. Cela fait seulement 6 jours depuis la rc2, mais je ne le fais pas seulement pour compenser la longue durée de sortie de la -rc2, je suis également à l’aéroport de San Diego, passant quelques jours ici avant le Kernel Summit.
Une -rc plutôt grosse, probablement parce que les gens se retiennent de me demander des intégrations pendant que je ne suis pas là : il y a donc des demandes en attente pour la -rc3.
Il y a un peu plus de la moitié en pilotes, un quart de mises à jour d’architecture et du vrac — principalement du réseau et du système de fichiers. Une fois le résumé joint, rien ici ne me fait dire « OMG! », ou m’incite à une remarque spécifique. La routine. Testez !

RC-4

La version RC-4 a été annoncée par Linus le 1^er septembre 2012 :

Le Kernel Summit étant fini, tout le monde ou presque est reparti de San Diego. Beaucoup de mainteneurs étaient donc absents et ces 10 jours depuis la -rc3 (au lieu de la traditionnelle semaine) ont été plutôt calmes.
Les statistiques sont en toute logique inhabituelles. Il y a 40 % de travail sur les architectures (PowerPC, x86, MIPS, ARM) ; 20 % sur Btrfs (des corrections mineures, parce que j’avais rejeté auparavant une demande d’intégration bien plus grosse) ; et seulement 20 % sur les pilotes, principalement des mises à jour sur DRM (Radeon pour la plupart) et quelques trucs sur libata et drbd.
J’ai joint le résumé, et comme vous pouvez le voir, il est tout sauf significatif. J’espère qu’on entre enfin dans la partie chiante et stable des -rc, et que tout ne va pas se remettre en branle juste parce que tout le monde est rentré chez lui.

RC-5

La cinquième version candidate du noyau a été annoncée par Linus le 8 septembre 2012 :

Ah ! Retour à la normale, une publication par semaine, le truc habituel, quoi.
La 3.6-rc5 est sortie, et tout a l’air assez tranquille. Peut‐être trop tranquille pour ne pas m’attendre au pire, c’est‐à‐dire quand Greg aura réussi à éponger son retard de courriel après le Kernel Summit, et son stage de kayak. Je soupçonne également d’autres développeurs d’avoir été calmes pour les mêmes raisons ou presque.
Je dois bientôt voyager encore, mais si ça reste calme, personne ne s’en rendra compte. Bref, quoi de neuf ? Pas grand chose — ce qu’il y a est bien réparti — et nous sommes revenus à la situation habituelle où le plus gros du travail est représenté par les pilotes : son, MMC, réseau (filaire ou non), PCI, vidéo.
Il y a aussi quelques mises à jour d’ARM (et PowerPC), quelques trucs sur CIFS et des petites corrections éparpillées. Le résumé est joint, constatez par vous‐mêmes.

RC-6

La version RC-6 a été annoncée par Linus le 16 septembre 2012 :

À nouvelle semaine, nouvelle sortie. Et comme je l’avais pensé, la -rc5 était légère parce que tout le monde se remettait du Kernel Summit. La -rc6 est un peu plus grosse : on se rattrape… Cela dit, elle n’est pas énorme non plus et n’a vraiment rien d’effrayant, mais elle n’est pas ridiculement petite.
Les stats sont normales : deux tiers de pilotes et un tiers de mises à jour d’architecture, de systèmes de fichiers (GFS2 et NFS) et un peu de trucs plus au cœur (scheduler, workqueue, etc.)
Testez‐moi tout ça, s’il vous plaît, j’aimerais bien sortir la 3.6 rapidos…

RC-7

Enfin, la version RC-7 a été annoncée par Linus le 23 septembre 2012 :

Hmm. J’aimerais vraiment vraiment dire que c’est la dernière -rc, mais il y a encore quelques trucs en attente… Il y aura peut‐être une -rc8, on verra bien.
Cela dit, ça n’a pas l’air mal. Vous en avez un bon aperçu en lisant le résumé joint : les modifications sont petites — des uni‐et‐quelques‐lignes. Rien n’a l’air inquiétant, même si les changements de powernow-k8/workqueue sont majeurs (mais ils résolvent un bogue et nettoient le code). Je pense que le plus gros patch est le correctif sur le « page table walking pour s390 », et même celui‐là n’est pas énorme.
Donc, si tout va bien et que la semaine qui arrive reste calme, je suppose que je pourrai éviter une autre -rc : croisons les doigts. Bref, lisez le résumé. La plupart des changements sont dans les pilotes (réseau, graphique, Infiniband, bloc…), dans les architectures (s390 et x86) et un peu de vrac (XFS, workqueue, réseau). Bien que ce soit des -rc, n’ayez pas peur de tester : tout devrait être stable. Le plus de tests on aura, le mieux ce sera.

Les nouveautés

Veille et hibernation combinée

Le développeur Bojan Smojver a écrit le patch permettant au noyau 3.6 d’offrir la fonction « suspend to both ».
Comme son nom l’indique, cette nouvelle fonction permet de combiner les fonctions de mise en veille et d’hibernation. De cette façon, le noyau Linux va tout d’abord faire un suspend to disk (sauvegarde du système sur le disque dur), suivi d’un suspend to RAM (sauvegarde du système dans la mémoire vive). On profite ainsi des avantages des deux techniques, puisque la sortie de veille est très rapide et que l’état du système est sauvegardé, même en cas de vidage complet de la batterie.
Cette fonction s’active avec la commande suivante :

echo suspend > /sys/power/disk; echo disk > /sys/power/state

Améliorations de TCP

Deux améliorations importantes de la pile TCP ont été intégrées dans le noyau Linux 3.6.
La première concerne le combat de longue haleine qui a été entrepris contre le « _bufferbloat » (l’engorgement des réseaux du fait de tampons mémoire trop gros). Le nouveau patch se nomme TCP Small Queues et il a été écrit par Éric Dumazet. Il s’agit de limiter la quantité de données qui peut être mise en file d’attente pour un socket. Cela permet de limiter l’engorgement sans se faire entourlouper par tous les tampons de la pile réseau (filtrage IP, contrôle du trafic, etc.).
On peut contrôler la limite en écrivant dans /proc/sys/net/ipv4/tcp_limit_output_bytes, la valeur par défaut étant de 128 Kio.

La seconde amélioration, nommée TCP Fast Open, est l’œuvre de Yuchung Cheng qui travaille chez Google. Il s’agit ici de réduire le temps de connexion lors de l’ouverture d’une session TCP.
La norme actuelle est celle de la poignée de main en trois temps (SYN, SYN-ACK, ACK), mais avec le nouveau patch, on peut établir une session TCP en seulement deux temps. L’idée générale est, pour le client, d’envoyer des données en même temps qu’il expédie son SYN initial. Comment est‐ce possible me direz‐vous ? Eh bien, il faut d’abord que la poignée de main en trois étapes ait déjà eu lieu au moins une fois. À cette occasion le client et le serveur vont échanger un cookie qui leur permettra de se reconnaître ultérieurement. Lors de leurs conversations ultérieures, le client pourra ainsi envoyer sa demande en même temps que son SYN et le serveur lui renverra le SYN-ACK, puis les données demandées, avant même d’avoir reçu le ACK final.
Toute cette mécanique est parfaitement bien décrite dans l’article LWN consacré à TCP Fast Open.
Pour l’instant, seul le code concernant le client a été intégré au noyau 3.6. Les patches portant sur la partie serveur seront intégrés par Yuchung Cheng dans le 3.7.

Suppression du cache de routage IPv4

Le cache de routage IPv4 était présent depuis un bon moment dans le noyau, puisqu’il était déjà présent dans le noyau 2.4.0. L’idée de départ était simple : lorsque le noyau reçoit ou veut émettre un paquet IP et savoir par quelle carte réseau il doit l’envoyer et à quel routeur (next hop), il effectue (pour simplifier) une recherche dans une table de routage IPv4. Mais, comme cela était lent et que les entrées demandées étaient souvent les mêmes, un cache de routage a été introduit pour permettre d’améliorer les performances, surtout pour les gros routeurs qui traitent des millions de paquets à la seconde.

Ce cache stockait directement la requête (par exemple : « je veux router vers 88.191.250.176 un paquet qui vient de 192.168.1.2 depuis l’interface eth1 ») et la réponse (« passe par eth0 en contactant 192.0.2.1 »), ainsi que des pointeurs vers des paramètres comme la mesure du PMTU ou les statistiques de TCP. Si vous n’utilisez pas encore ce noyau 3.6, vous pouvez consulter votre propre cache de routage IPv4 avec ip route show cache.

Mais rapidement, ce cache a montré des signes de faiblesse. D’une part, il fallait le maintenir à jour et vider périodiquement les entrées devenues trop vieilles, et lorsque la table de routage était changée, il fallait vider ce cache. D’autre part, cela rendait les performances dépendantes du nombre de flux sur le réseau, puisque le cache de routage reflétait les flux utilisés. Si le noyau devait router un million de paquets vers la même destination, alors il n’y avait qu’une seule entrée dans le cache de routage, mais si le noyau devait router un million de paquets vers un million de destinations différentes, alors il se produisait un grand nombre d’évictions du cache de routage. Et ce, même si la table de routage de départ était extrêmement simple et que tous ces paquets devaient, au final, passer par le même prochain routeur. Ce problème était rédhibitoire sur les gros routeurs, qui voyaient passer des millions de flux différents (on parle d’un cache hit de seulement 10 %, donc le cache de routage n’était utile que pour un paquet sur dix). Sur une machine plus modeste, un attaquant pouvait exploiter ce problème pour surcharger la machine, ce qui a posé des problèmes de sécurité dans le passé.

Le travail de David Miller consistant à refondre le cache de routage a duré environ deux ans (l’idée a commencé à émerger après la sortie de 2.6.37) et, dans son courriel récapitulatif, il a tenu à remercier particulièrement Julian Anastasov, Éric Dumazet et Steffen Klassert.
Cela n’a pas été de tout repos, car c’est un changement assez invasif, et que peu de personnes ont participé… À tel point que David Miller a dû pousser une gueulante pour que ses patches soient testés. C’est finalement dans ce noyau 3.6 que les patches ont été intégrés.

Ces patches suppriment le cache de routage, multiplient par deux les performances de la recherche dans les tables de routages classiques, et introduisent un autre cache, plus simple, directement à l’intérieur de l’entrée de routage, pour stocker les informations supplémentaires (PTMU, stats TCP…) qui étaient initialement dans le cache.

Améliorations Btrfs

Une interface permettant de générer un diff entre deux volumes Btrfs a été ajoutée à la panoplie des outils de ce système de fichiers.
Avec Btrfs, il est extrêmement facile de créer un instantané du système à n’importe quel moment (c’est‐à‐dire de capturer l’état global du système de fichiers). Ce qui est moins facile, c’est d’examiner les différences qui existent entre deux instantanés.
Le nouvel outil send/receive (largement inspiré de la fonction équivalente sous ZFS) vise justement à améliorer ce point.
Grâce à cette nouvelle fonction, il est possible de ne sauvegarder que les différences entre les instantanés et, en cas de besoin, de régénérer le système complet à partir de ce diff.
La syntaxe d’utilisation est simple, puisqu’il suffit d’un btrfs send -i oldsnap snapshot pour créer un diff par rapport à oldsnap.

Parmi les autres nouveautés de Btrfs listées dans le courriel récapitulatif de Chris Mason, on peut citer notamment la gestion des quotas sur les sous‐volumes.
Cela permet de gérer l’allocation des blocs et de fixer des limites pour chaque sous‐volume et chaque instantané. Comme l’indique Chris, « c’est tout ce dont a besoin une société proposant de l’hébergement Web pour offrir un sous‐volume à chacun de ses utilisateurs ».

Améliorations dans la gestion de l’entropie

Tout est parti de la publication d’un article inquiétant, écrit par des chercheurs issus de l’Université de Californie. Dans ce papier, des faiblesses étaient signalées dans les clés RSA et DSA de nombreux équipements réseau embarqués. Les chercheurs ont indiqué qu’ils avaient trouvé des clés faibles, issues de tous les systèmes (sont cités GNU/Linux, Windows et FreeBSD), mais ils se sont particulièrement penchés sur le générateur de nombres aléatoires de Linux, afin de l’analyser en profondeur.

À la suite de cette étude, les développeurs du noyau ont décidé qu’il était temps de renforcer les mécanismes de gestion de l’entropie de Linux. Les équipements embarqués ont moins de sources d’entropie que les machines de bureau (les intervalles de frappe clavier, par exemple), et il faut donc dimensionner la fonction en pensant à ces équipements.
C’est Theodore Ts’o qui s’est attelé à ce travail, en collectant les patches des autres développeurs dans une branche spécifique.
Le noyau prend donc désormais en compte diverses sources additionnelles, pour brasser encore plus les réservoirs d’entropie (random pool), comme les numéros de série et les noms des fabricants des périphériques USB, l’adresse MAC ou encore les tables DMI du BIOS.
On peut noter que nombre de ces patches ont été rétroportés sur les noyaux bénéficiant d’un support à long terme.

Pilotes graphiques

Peu de nouveautés sur les pilotes graphiques incorporés au noyau 3.6. Dave Airlie a même écrit dans son courriel récapitulatif qu’il s’agissait de « one of the smaller drm -next pulls in ages » !
On trouve néanmoins quelques patches intéressants, puisque le pilote Radeon gère officiellement par défaut les modes à haute vitesse de PCIe 2.0. C’est un gain en vitesse qui peut être appréciable, et qui n’avait pas été activé jusqu’à présent, à cause de divers bogues.
Il ne reste plus maintenant qu’à travailler sur le PCI Express 3.0…
Du côté de Nouveau, pas de changements, à part des corrections de bogues. L’inclusion d’un gros travail de réécriture effectué par Ben Skeggs, a été reporté au noyau 3.7.
Enfin, Intel peaufine son pilote i915, pas mal de nettoyage, pour encore améliorer les performances d’Ivy Bridge. On note aussi l’ajout de la prise en charge des divers cœurs graphiques des futurs processeurs Haswell.

ext4

Deux changements notables dans le système de fichiers ext4 ont été intégrés au noyau 3.6.
Tout d’abord, une optimisation a été effectuée pour les cas de réécriture en parallèle de données sur le disque (parallel non‐allocating writes). Alors qu’avant, il fallait tenir un verrou i_mutex, le patch de Zheng Liu permet astucieusement d’éviter cette coûteuse opération.
Ensuite, suivant en cela les plans décrits dans cette entrée du wiki ext4, les quotas sur le système de fichiers sont maintenant pris en charge nativement. Alors qu’avant, ces quotas étaient stockés dans des fichiers à part, le patch d’Aditya Kali permet de stocker ces informations user.quota et group.quota en tant que métadonnées dans les nœuds d’index (inodes) du système de fichiers. Tout cela est géré par e2fsprogs et devient actif aussitôt que le montage est effectué.

Gestion de l’énergie sur ATA et PCIe

Intel, par l’intermédiaire des développeurs Huang Ying, Zheng Yan et Lin Ming, a proposé plusieurs patches permettant de mieux gérer la consommation des périphériques ATA et PCIe.
Il s’agit ici d’exploiter au mieux le nouveau mode d’endormissement D3 Cold qui fait partie des spécifications PCI Express 2.0 et ACPI 5.0.
Précédemment, il existait le D3 Hot, mais avec le nouveau mode on économise encore plus, puisque le périphérique est complètement stoppé. En fait, on ne peut plus du tout communiquer directement avec lui, et il faut passer par ACPI pour le réveiller. D’ailleurs, certains périphériques, ceux qui ont des tables ACPI « fantaisistes », ont dû être placés dans une liste noire n’utilisant pas D3 Cold.
Bien entendu, cette économie de consommation sur les périphériques compatibles se paie par un temps de réveil en augmentation. Le noyau doit donc faire jouer son infrastructure de gestion de l’énergie (PM, pour Power Management) afin de prendre les bonnes décisions.
En plus des périphériques PCIe, le sous‐système libata a été également modifié afin qu’il puisse lui aussi tirer partie de D3 Cold. Il est probable que les futures versions du noyau utiliseront ces nouvelles fonctions de la libata pour implémenter l’économie d’énergie sur les lecteurs de disques optiques (ZPODD, pour Zero‐Power Optical Disk Drive).

Restriction sur la création de liens

Afin d’augmenter la sécurité, certaines restrictions sur la création de liens, longtemps controversées, longtemps discutées, ont été intégrées dans le noyau.

C’est Kees Cook qui est l’auteur de ce patch permettant de sécuriser l’utilisation des liens symboliques (symlinks) et des liens matériels (hardlinks). Il s’agit ici de bloquer une vulnérabilité faisant partie de la classe des attaques TOCTTOU (time of check to time of use). Entre le moment où un processus vérifie qu’un fichier existe (le check) et le moment où il l’utilise (le use), on peut interposer un lien symbolique pour diriger le processus victime vers la charge utile. Ces attaques s’effectuent dans un répertoire accessible à tous (souvent /tmp) et elles sont particulièrement graves si le processus abusé est un programme permettant le changement d’utilisateur lors de son exécution (setuid).

En ce qui concerne ces attaques TOCTTOU dans /tmp, les développeurs du noyau ont fait preuve d’une inertie coupable, puisque divers patches existent depuis plus de 15 ans et que la protection est intégrée en standard dans des distributions visant la sécurité, notamment GRSecurity et OpenWall, mais aussi dans Ubuntu depuis près de deux ans. Le patch de Kees réutilise ces idées, ainsi que les conseils judicieux d’Al Viro, le grand manitou du VFS.
Deux nouveaux sysctl ont été introduits afin de permettre de contrôler le fonctionnement de ces restrictions.

Quand protected_hardlinks est mis à 0, alors rien ne change par rapport au comportement habituel. Quand il est mis à 1, alors il est impossible pour un utilisateur de créer un lien matériel s’il ne possède pas déjà des droits en lecture et écriture sur le fichier source.
Même chose pour protected_symlinks. Cette fois, quand on se trouve dans un répertoire accessible à tous, la valeur 1 permet de suivre un lien symbolique, uniquement si celui qui suit le lien est le même que celui qui l’a créé (même uid).

Il est difficile de comprendre pourquoi ces restrictions sur les liens n’ont pas été intégrées plus tôt à la couche VFS du noyau. Les réfractaires pointaient une incompatibilité avec la norme POSIX ou encore un risque de dysfonctionnement de certaines applications. Kees a bien pris soin de préciser que POSIX était assez vague sur ce sujet et que la restriction des liens ne violait donc pas la norme. Quant aux applications, on peut les corriger (le démon at a d’ailleurs été « patché »), donc l’objection ne tient pas.
Il reste à espérer que les développeurs se montreront plus coopératifs à l’avenir et, pourquoi pas, soyons fous, arriveront à se mettre d’accord sur une solution pour empiler les modules de sécurité (LSM Stacking).

En vrac

• Avec le noyau 3.6, il est maintenant possible de d’utiliser un fichier d’échange mémoire (swap) sur une machine distante via NFS. Cette nouvelle possibilité apporte un choix supplémentaire par rapport au plus classique échange via NBD (Network Block Device). C’est la conclusion d’un long travail de Mel Gorman et Peter Zijlstra. Voir cet article LWN datant de 2011 pour plus de détails.

• Le développeur Shaohua Li a optimisé le fonctionnement de Linux dans le cas de disques SSD en RAID. Les algorithmes de distribution du travail entre les disques étaient jusqu’à présent basés sur le présupposé qu’il s’agissait de disques durs rotatifs classiques. Shaohua Li a donc proposé de nouvelles stratégies mieux adaptées aux SSD pour répartir les données. Dans certains cas, il observe un gain de débit allant jusqu’à 50 %.

• Le code cpuidle, celui qui s’occupe de prendre les décisions pour entrer ou pas dans les divers mode d’économie des processeurs, a été amélioré. Il prend désormais en charge les processeurs dont les cœurs ne peuvent pas être gérés séparément. La modif de Colin Cross, un développeur Android, autorise maintenant ce couplage des modes d’économie dans le noyau 3.6.

• Éric Dumazet a optimisé la lecture de la table /proc/net/unix qui liste tous les sockets locaux ([[UNIX domain sockets]]). Alors qu’auparavant la lecture de cette table avait un coût en O(n²) (complexité quadratique) l’utilisation d’une table de hachage permet de réduire le coût de lecture de manière drastique. Éric signale dans son message de commit que le temps mis à lire une table de 200 000 sockets passe de 520 secondes à seulement 2 secondes.

• Le nouveau sous‐système VFIO (Virtual Function I/O) a été intégré dans le noyau. Il permet de créer plus facilement des pilotes en espace utilisateur. De cette manière, les machines virtuelles comme KVM peuvent utiliser des pilotes PCI ou PCIe ayant de grandes performances (accès direct à la mémoire DMA) et un fonctionnement sûr (gestion de la mémoire par IOMMU). Voir cet article LWN, la documentation de VFIO ou encore ces tranparents de Jörg Rödel.

• Toujours dans le domaine des pilotes en espace utilisateur (non, Linux ne devient pas un micro‐noyau !) on peut noter l’arrivée du sous‐système UHID qui propose de gérer les entrées‐sorties des périphériques HID (c’est‐à‐dire les périphériques USB ou Bluetooth) directement en espace utilisateur. Le patch de David Herrmann facilite donc l’écriture de ces pilotes HID, puisque toute la partie de gestion des E‐S peut se faire en espace utilisateur et les données sont envoyées au noyau dans le sous‐système HID classique (voir la documentation).

• L’outil de traçage perf est maintenant capable d’examiner la partie « uncore » des processeurs Nehalem et _Sandy Bridge. Cette partie regroupe les fonctions qui ne font pas partie des cœurs de calcul proprement dits. On retrouve donc le cache L3, les contrôleurs mémoire, le gestionnaire d’énergie PCU, ainsi que le bus QPI.

• Le développeur Anton Blanchard (n’oubliez‐pas que « all your base are belong to Anton Blanchard » !) a optimisé les routines de pré‐chargement mémoire pour l’architecture POWER7 d’IBM. S’appuyant en partie sur le jeu d’instructions vectorielles VMX, les patches accélèrent de 17 % le code faisant un usage intensif de copy_page et de 12 % le code faisant appel à l’instruction memcpy.

• Le pare‐feu Netfilter peut désormais profiter de l’aide de divers programmes en espace utilisateur (les helpers) pour faire du suivi de connexion (connection tracking). Une infrastructure de communication entre Netfilter et ces helpers a été écrite par Pablo Neira Ayuso qui explique dans son patch l’intérêt de ce mécanisme.

• La gestion du bus CAN (Controller Area Network), très utilisé dans l’industrie automobile, est améliorée dans le nouveau noyau. Le développeur Oliver Hartkopp, employé par Volkswagen, a ajouté la gestion de la nouvelle norme CAN FD qui permet d’envoyer 64 octets de données par trame au lieu de huit. Vous pouvez consulter la documentation ou bien, plus vulgarisé, l’article dédié sur la CAN Newsletter.

• Le développeur Michael Tsirkin a travaillé sur une micro‐optimisation de la machine virtuelle KVM. Son code porte sur une amélioration des temps de traitement des interruptions (et notamment les EOI). Grâce à ses patches, il a observé une réduction notable du temps passé lors des opérations kvm_entry et kvm_exit (quasi division par deux selon ce banc d’essai).

• Un autre patch, écrit cette fois par Christian Ehrhardt, vise également à améliorer les performances des machines gérant de nombreuses instances KVM. Le travail porte sur la gestion de l’échange mémoire (swap) dans un scénario où les disques sont sur un SAN. Le code permet maintenant de fusionner les requêtes, ce qui conduit, selon les tests effectués, à un gain en débit compris entre 10 % et 40 %, ainsi qu’à une baisse de la consommation processeur.

• Les algorithmes de chiffrement symétrique Serpent et Twofish peuvent maintenant, grâce au travail de Johannes Goetzfried, bénéficier d’un code assembleur optimisé pour les instructions vectorielles AVX. Certes, il vous faudra un processeur récent (minimum Sandy Bridge chez Intel et Bulldozer chez AMD), mais le gain est intéressant. Il se limite à environ 6 % pour Serpent, mais peut monter à plus de 30 % pour Twofish, par rapport à l’assembleur x86-64 standard.

Statistiques

En ce qui concerne les statistiques du cycle de développement du noyau 3.6, le site LWN a publié son traditionnel article récapitulatif (disponible en s’inscrivant ou en attendant le 4 octobre).
En termes de patches, le total s’établit à 10 226 (au 29 septembre), alors qu’il était de 10 955 pour le noyau précédent. C’est maintenant devenu une solide habitude que de dépasser les 10 000 patches tous les deux mois et demi.
Environ 523 000 lignes de code ont été ajoutées et 252 000 supprimées, pour un accroissement total d’environ 271 000 lignes. Le noyau 3.6 devrait donc approcher les 16 millions de lignes de code en tout.

Cette fois, ce sont 1 251 développeurs différents qui ont proposé au moins un patch dans ce cycle. Le champion en haut du palmarès est H. Hartley Sweeten avec 460 patches portant sur le nettoyage du sous‐système Comedi (périphériques d’acquisition de données), afin de le faire sortir de la branche -staging. En seconde position, avec 175 patches, on retrouve notre ami Mark Brown, qui était médaille d’or sur le 3.3 et le 3.4. Employé par Wolfson Microelectronics, il continue de travailler sur l’amélioration ou la restructuration des multiples pilotes audio du noyau. Enfin, David Miller apparaît en troisième position dans la liste des contributeurs, du fait de son travail sur la pile réseau et notamment de ses patches de suppression du cache de routage IPv4.

Un autre classement intéressant qui est évoqué dans l’article LWN, est celui des étiquettes (tags) Reported-by. Les développeurs apposent cette étiquette pour garder la trace (et pour remercier) des personnes ayant découvert un bogue et ayant pris la peine de le signaler.
Le premier de ce classement, avec 44 étiquettes, est le développeur Fengguang Wu. Il est particulièrement difficile d’essayer de le concurrencer à ce petit jeu des rapports de bogues, puisqu’il dirige l’infrastructure de build/boot testing mise en place par Intel dans leur Open Source Technology Center.
Je vous invite à aller lire l’article fascinant publié par LWN, qui décrit cette infrastructure de test. Juste pour vous mettre l’eau à la bouche, voici quelques chiffres : plus de 100 instances KVM différentes, sur des machines x86-64 et Itanium, compilation et amorçage du noyau pour chaque nouveau commit venant de plus de 180 branches de développement distinctes. Un total d’environ 30 000 noyaux testés par jour !

Peu de changements sont à noter dans le classement par entreprise (Red Hat et Intel dominent toujours les listes de contributions), mais l’embauche de Greg Kroah-Hartman par la Linux Foundation fait tout de même bouger les lignes.
Annoncé sur son blog par un lapidaire sed -i 's/gregkh@suse.de/gregkh@linuxfoundation.org/g' .addressbook, le recrutement de Greg fait mécaniquement reculer SUSE au classement des entreprises contributrices. C’est surtout en termes de lignes modifiées que Greg apparaît dans le classement, puisqu’il supervise la branche -staging et qu’il peut donc ajouter ou supprimer des pilotes en un seul commit.
Une autre conséquence est la progression de la Linux Foundation dans le classement des étiquettes Signed-off-by (seconde position derrière Red Hat avec 1 278 étiquettes). Ces étiquettes Signed-off-by servent à garder la trace des développeurs ayant approuvé l’inclusion d’un patch, et ils sont donc de bons marqueurs pour connaître les gardiens du noyau. Greg Kroah-Hartman étant l’un des plus prolifiques de ces gardiens, il est clair que la Linux Foundation a fait une bonne affaire en l’embauchant… Et pour le même prix, elle gagne un dieu du skate‐board !

Aller plus loin

• L’annonce du noyau 3.6 sur la liste de diffusion du noyau (339 clics)
• Les nouveautés du noyau sur le site H-online (596 clics)
• LWN 1 : Les nouveautés du noyau 3.6 (469 clics)
• LWN 2 : Les nouveautés du noyau 3.6 (202 clics)
• LWN 3 : Les nouveautés du noyau 3.6 (198 clics)