URL: https://linuxfr.org/news/sortie-du-noyau-linux-3-6 Title: Sortie du noyau Linux 3.6 Authors: patrick_g detail_pratique, Davy Defaud, baud123, warwick, Batchyx, Benoît, David Bonnin, samo, stiffux, ymorin, Patrice G., Grégoire Seux, Xavier Teyssier, Sébastien Koechlin, Olivier Esver, claudex, Philip Marlowe, voondo, M, Florent Zara et maboiteaspam Date: 2012年08月06日T16:21:15+02:00 License: CC By-SA Tags: linux, kernel, noyau_linux, coulisses, linus_torvalds, ubuntu et grsecurity Score: 113 La sortie de la version stable 3.6 du noyau Linux [vient d’être annoncée](https://lkml.org/lkml/2012/9/30/152) par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site [_kernel.org_](http://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](http://creativecommons.org/licenses/by-sa/3.0/deed.fr)). 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._ ---- [L’annonce du noyau 3.6 sur la liste de diffusion du noyau](https://lkml.org/lkml/2012/9/30/152) [Les nouveautés du noyau sur le site H-online](http://www.h-online.com/open/features/What-s-new-in-Linux-3-6-1714690.html) [LWN 1 : Les nouveautés du noyau 3.6](https://lwn.net/Articles/507852/) [LWN 2 : Les nouveautés du noyau 3.6](https://lwn.net/Articles/508790/) [LWN 3 : Les nouveautés du noyau 3.6](https://lwn.net/Articles/509433/) ---- #La phase de test ## RC-1 La version [RC-1](http://article.gmane.org/gmane.linux.kernel/1337052) 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](http://fr.wikipedia.org/wiki/A%C3%A9roport_international_de_Portland) ! ), 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](https://lkml.org/lkml/2012/8/16/577) 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](https://lkml.org/lkml/2012/8/22/615) 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](https://lkml.org/lkml/2012/9/1/98) a été annoncée par Linus le 1^er septembre 2012 :> _Le_ [Kernel Summit](https://lwn.net/Articles/KernelSummit2012/) _é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](https://lkml.org/lkml/2012/9/8/208) 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](https://lkml.org/lkml/2012/9/16/102) 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](https://lkml.org/lkml/2012/9/23/143) 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_](https://lkml.org/lkml/2009/3/16/199) »_, 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_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=62c552ccc3eda1198632a4f344aa32623d226bab) 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](https://lwn.net/Articles/507065/) concerne le combat de longue haleine qui a été entrepris contre le « [_bufferbloat](http://linuxfr.org/news/sortie-du-noyau-linux-3-3#toc_11) » (l’engorgement des réseaux du fait de tampons mémoire trop gros). [Le nouveau _patch_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=46d3ceabd8d98ed0ad10f20c595ca784e34786c5) 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](http://fr.wikipedia.org/wiki/Transmission_Control_Protocol#.C3.89tablissement_d.27une_connexion) (SYN, SYN-ACK, ACK), mais avec le nouveau [_patch_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=783237e8daf13481ee234997cbbbb823872ac388), 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](https://lwn.net/Articles/508865/) 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é](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0244) 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](http://article.gmane.org/gmane.linux.network/185987)) et, dans [son courriel](http://article.gmane.org/gmane.linux.network/238256) 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](http://article.gmane.org/gmane.linux.network/237956). 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_](https://lwn.net/Articles/506244/) (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](http://article.gmane.org/gmane.linux.kernel/1333887), 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](https://factorable.net/) 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](https://lwn.net/Articles/507115/) 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](http://article.gmane.org/gmane.linux.kernel/1335879). 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](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b04b3156a20d395a7faa8eed98698d1e17a36000), [l’adresse MAC](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7bf2357524408b97fec58344caf7397f8140c3fd) ou encore les [tables DMI](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d114a33387472555188f142ed8e98acdb8181c6d) 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](http://lists.freedesktop.org/archives/dri-devel/2012-July/025524.html) 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](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=197bbb3d464f33eac1b458e83c1929d2f268d4c9) 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](http://www.h-online.com/open/features/Kernel-Log-Major-overhaul-of-Nouveau-1664869.html) 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_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=da612d880fbc598ac0efcef579355fb90d4bca4e). ##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](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4bd809dbbf177ad0c450d702466b1da63e1b4b7e) permet astucieusement d’éviter cette coûteuse opération. Ensuite, suivant en cela les plans décrits dans [cette entrée du wiki _ext4_](https://ext4.wiki.kernel.org/index.php/Design_For_1st_Class_Quota_in_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_](http://fr.wikipedia.org/wiki/_inodes_ "Définition Wikipédia")) 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](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=448bd857d48e69b33ef323739dc6d8ca20d4cda7) 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](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=71a83bd727cc31c5fe960c3758cb396267ff710e) 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é](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3bd46600a7a7e938c54df8cdbac9910668c7dfb0) 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_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=800179c9b8a1e796e441674776d11cd4c05d61d7) permettant de sécuriser l’utilisation des liens symboliques ([_symlinks_](http://fr.wikipedia.org/wiki/Lien_symbolique)) et des liens matériels ([_hardlinks_](http://fr.wikipedia.org/wiki/Lien_mat%C3%A9riel)). Il s’agit ici de bloquer une vulnérabilité faisant partie de la classe des attaques [TOCTTOU](http://en.wikipedia.org/wiki/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_](http://fr.wikipedia.org/wiki/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`](http://fr.wikipedia.org/wiki/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é »_](http://anonscm.debian.org/gitweb/?p=collab-maint/at.git;a=commitdiff;h=f4114656c3a6c6f6070e315ffdf940a49eda3279)), 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](http://thread.gmane.org/gmane.linux.kernel/1326658). 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](https://lwn.net/Articles/439298/) datant de 2011 pour plus de détails. - Le développeur [Shaohua Li a optimisé le fonctionnement de Linux](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9dedf60313fa4dddfd5b9b226a0ef12a512bf9dc) 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`](https://lwn.net/Articles/384146/), 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](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4126c0197bc8c58a0bb7fcda07b01b596b6fb4c5), 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(n2) (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_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7123aaa3a1416529ce461e98108e6b343b294643) 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](http://fr.wikipedia.org/wiki/Direct_Memory_Access)) et un fonctionnement sûr (gestion de la mémoire par [IOMMU](http://fr.wikipedia.org/wiki/en:IOMMU "Définition Wikipédia")). Voir [cet article LWN](https://lwn.net/Articles/474088/), la [documentation de VFIO](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/vfio.txt;h=0cb6685c802904c0d7becccb00e3a00321bfb928;hb=4a5b2a20ec87384eeb19e70991e7e15a00cad87b) ou encore [ces tranparents](http://www.8bytes.org/~joro/slides-lt2012.pdf) 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](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1ccd7a2a33f2b47e46c51f4501e9623a51d28090) 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](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/hid/uhid.txt;h=4627c4241ece699cedbe6660c7754e12933c4c2c;hb=d99b8bad7663c8b920b366877a27b4176dece062)). - L’outil de traçage `perf` est [maintenant capable](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7c94ee2e0917b2ea56498bff939c8aa55da27207) 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_](http://antonblanchardfacts.com/) » !) a optimisé les routines de pré‐chargement mémoire pour l’architecture [POWER7](http://fr.wikipedia.org/wiki/POWER7 "Définition Wikipédia") d’IBM. S’appuyant en partie sur le jeu d’instructions vectorielles VMX, les _patches_ [accélèrent de 17 %](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fde69282b7ba2701560764b81ebb756deb98cf2b) le code faisant un usage intensif de `copy_page` et [de 12 %](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b3f271e86e5a440713716bb222e1aa1227994c50) le code faisant appel à l’instruction `memcpy`. - Le pare‐feu [_Netfilter_](http://fr.wikipedia.org/wiki/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_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=12f7a505331e6b2754684b509f2ac8f0011ce644) l’intérêt de ce mécanisme. - La gestion du bus CAN ([_Controller Area Network_](http://fr.wikipedia.org/wiki/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](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ea53fe0c667ad3cae61d4d71d2be41908ac5c0a4) ou bien, plus vulgarisé, [l’article dédié](http://can-newsletter.org/engineering/standardization/nr_stand_can-fd_linux3.6_120703/) sur la _CAN Newsletter_. - Le développeur Michael Tsirkin a travaillé sur une micro‐optimisation de la machine virtuelle KVM. [Son code](http://thread.gmane.org/gmane.comp.emulators.kvm.devel/91775) porte sur une amélioration des temps de traitement des interruptions (et notamment les [EOI](http://en.wikipedia.org/wiki/End_of_interrupt)). 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](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ab9cf4996bb989983e73da894b8dd0239aa2c3c2)). - 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](http://fr.wikipedia.org/wiki/R%C3%A9seau_de_stockage_SAN). Le code permet maintenant de fusionner les requêtes, ce qui conduit, selon [les tests effectués](http://git.kernel.org/?p=linux/kernel/git/jkirsher/net.git;a=commitdiff;h=3fb5c298b04eb6e472f8db1f0fb472749d30041c), à 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_](http://en.wikipedia.org/wiki/Serpent_%28cipher%29) et [_Twofish_](http://en.wikipedia.org/wiki/Twofish) peuvent maintenant, grâce au travail de Johannes Goetzfried, bénéficier d’un code assembleur optimisé pour les [instructions vectorielles AVX](http://en.wikipedia.org/wiki/Advanced_Vector_Extensions). 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_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7efe4076725aeb01722445b56613681aa492c8d6), mais peut monter à [plus de 30 % pour _Twofish_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=107778b592576c0c8e8d2ca7a2aa5415a4908223), 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](https://lwn.net/Articles/517564/) (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_](http://www.comedi.org/) (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](https://lwn.net/Articles/514278/) 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_](http://www.linuxfoundation.org/news-media/announcements/2012/01/leading-kernel-maintainer-greg-kroah-hartman-joins-linux-foundation) fait tout de même bouger les lignes. [Annoncé sur son _blog_](http://www.kroah.com/log/diary/2012_01_31.html) 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](http://www.linuxfoundation.org/news-media/blogs/browse/2012/09/skateboarding-greg-kroah-hartman) !

AltStyle によって変換されたページ (->オリジナル) /