Sommaire
La phase de test
-rc1
La version -rc1 a été annoncée par Linus le 3 juin 2012 :
Je l'ai donc mise à disposition hier, mais je n'ai pas écrit de message à ce propos parce que je ne me sentais pas d'attaque.
C'est une version assez classique — grosso-modo 60 % pour les pilotes, 20 % de mises à jour dans arch, et 20 % un peu partout ailleurs — systèmes de fichiers, documentation, outils, etc.
Rien de particulier ne me vient à l'esprit — il y a quelques problèmes de compactage de la mémoire pour lesquels une discussion est en cours, mais je ne pense pas qu'il y ait quoi que ce soit de particulièrement effrayant ou spécial qui sorte du lot dans cette -rc1.
Ci-dessous se trouve mon « journal résumé des merges » — en grande partie généré automatiquement à partir de mes messages de fusions. Il y a probablement quelques merges manquants simplement dues au fait qu'il est généré à partir de mes messages non formatés qui tendent à avoir un format particulier, mais si j'ai merdé quelque part, cela n'aura pas forcément déclenché mon grep. Notez aussi que le « de xyz » concerne la personne qui m'a envoyé la demande d'inclusion, et non qui l'a codée (et quelques dépôts — arm-soc et x86 en particulier — tendent à avoir plusieurs mainteneurs, donc la personne m'envoyant la demande d'inclusion n'est pas forcément l'unique propriétaire du dépôt, juste le « point de contact »).
Selon vos centres d'intérêt, vous pourrez être intéressés par l'ordonnanceur de paquets CoDel, ou par les mises à jour des pilotes GPU, ou par les nouvelles cibles SCSI. Il y a un peu de tout pour pratiquement tout le monde.
-rc2
La version -rc2 est sortie le 8 juin 2012 :
Ok, cela ne fait que 6 jours, mais comme dit précédemment je serai en voyage à partir de demain, et je voulais rendre la -rc2 disponible avant de partir.
J'aurai accès à internet, mais à voir mon agenda, je n'aurai probablement pas beaucoup de temps, donc vous feriez mieux de me considérer comme absent durant une semaine. Autrement dit, s'il n'y a rien de vraiment critique, ne vous fatiguez pas à me demander d'inclure votre travail. Voyez ça comme une de ces semaines où je fais mon difficile sur tout, et deviens grincheux quand les gens m'envoient des petits machins sans pertinence qui ne sont pas des correctifs pour des oops importants.
Cela dit, je pense que -rc2 est plutôt en bon état, et j'ai tenté de retirer de manière assez agressive les modifications qui posaient problème (et parfois les choses qui n'étaient que suspectées d'être la cause de problèmes).
Nous avons l'assortiment habituel de correctifs : pilotes (gpu, i2c, acpi, clocksource), architectures (principalement x86 perf, mais aussi quelques trucs triviaux pour powerpc et parisc), systèmes de fichiers (fuse, cifs, ext4, ubifs), le tout accompagné de mises à jour VM, de la documentation, et des correctifs timer, irq et ordonnanceur.
En avant pour les tests.
-rc3
La version -rc3 est disponible depuis le 16 juin 2012.
À cette étape, je souhaite toujours qu'il y ait moins de modifications dans les versions -rc, mais -rc3 est disponible, et bien qu'elle pourrait être plus petite (il y a à peine moins de 300 modifications), ce n'est pas trop mal.
La semaine a démarré tranquillement avec juste quelques petites modifications, où les gens semblaient vraiment me faciliter la vie en déplacement – merci. Mais ça a quelque peu dégénéré en cours de route, et je pense que plus de la moitié des demandes d'inclusions de modifications sont arrivées durant les deux derniers jours et étaient plus invasives aussi.
Bon c'est comme ça…
-rc4
Linus a rendu la version -rc4 disponible ce 24 juin 2012:
Une nouvelle semaine, une nouvelle -rc.
Beaucoup de petits correctifs ici. Je pense que la plus grosse (en nombre de lignes) modification est le correctif de la fonctionnalité kmsg_dump() qui a été cassée du fait du nouveau mécanisme d'enregistrement des messages du noyau.
Ainsi, alors que nous avons 200+ modifications dans cette -rc, elles sont toutes plutôt petites et insignifiantes. Bien sûr, si ce problème dorénavant corrigé vous a frappé (ou que vous êtes le développeur de ces lignes de code révolutionnaires ;), vous serez éventuellement en désaccord avec la partie « insignifiante », mais d'après moi, c'est ainsi que j'aime les -rc à cette étape.
Les statistiques pour les -rc sont somme toute étonnantes : quasi exactement un tiers pour les architectures, les pilotes et le « reste ». Habituellement les pilotes dominent la mêlée, mais je devine que cette fois nous n'avons pas eu que les patchs pour la plate-forme arm, mais aussi pas mal de mises à jour diverses du côté des systèmes de fichiers et de la documentation ce qui aboutit à cette répartition inhabituelle.
Toutefois, espérons que la tendance aux corrections triviales continue, et nous serons en bonne voie pour la mise à disposition de la version 3.5.
-rc5
La version -rc5 a été mise à disposition par Linus le 30 juin 2012.
À nouvelle semaine, nouvelle -rc. Celle-ci est plus classique que la rc4, vu que les pilotes représentent à nouveau 60+%. Probablement du fait des modifications de la pile réseau, ajoutées depuis la rc4.
Les stats ont l'air plus crades, parce que bien que les modifications étaient globalement petites, la correction de printk ressort clairement. Mais c'était une vraie régression par rapport au 3.4, donc ce n'est pas comme si c'était contestable. UDF est également devenu plus prudent au moment de monter des systèmes de fichiers corrompus – et c'est aussi visible dans les stats – mais c'est en partie dû au fait que les vérifications ont été nettoyés et déplacées dans une fonction, en les rendant plus complètes. Donc les changements effectifs sont plus petits qu'ils n'en ont l'air.
Bref, pas de quoi s'inquiéter à ce stade. Malgré le merge de la pile réseau (qui est plutôt dodu), -rc5 est plus petite que -rc4, même s'il y a quelques commits de plus ; ça va dans la bonne direction.
En résumé : mises à jour réseau, corrections de systèmes de fichiers, quelques petites mises à jour d'architectures (x86, arm, ppc) et un peu de bruit aléatoire.
Dites-moi (sur lkml) si vous avez encore des régressions.
-rc6
La version -rc6 a été mise à disposition par Linus le 7 juillet 2012.
Une semaine de plus, une -rc de plus. Et heureusement une semaine de calme. Sensiblement moins de commits dans celle-là que dans la -rc5, et je pense que nous sommes proche de la version finale.
Cela dit, c'est également l'été (nos co-développeurs australiens peuvent ne pas être d'accord mais ils sont en minorité), et avec ça je voulais également parler de la nouvelle fenêtre de merge. Parce que je suspecte notamment que beaucoup de développeurs européens sont partis en vacances ou sont en train de se préparer à le faire. Août a tendance à être une période de basse saison pour beaucoup de gens. J'espère que les projets de cet été ne sont pas majoritairement responsables du ralentissement du nombre de patches dans cette rc, mais je soupçonne que la prochaine fenêtre de merge sera presque inévitablement complètement éclipsée pour les développeurs en vacances.
C'est normal, et j'espère que ça va signifier que la sortie de la 3.6 va être plus calme. Je demande aux personnes qui vont en vacances de ne pas m'envoyer leurs patches dans la fenêtre de merge avant de partir. Je préfère vraiment avoir des merges différés à la 3.7 qu'un développeur qui m'envoie les gros changements puis disparait pour la publication des rc.
En tout cas, gardez ça en tête, particulièrement ceux d'entre vous qui prévoient de partir tout le mois d'août.
Retour sur les trucs de la -rc6 : il y a principalement des changements sur btrfs et md dans celle-là, avec des modifications classiques sur les pilotes, des mises-à-jour de Arm, des modifications réseaux, et quelques trucs aléatoires (dont de la doc etc). Rien de bien effrayant, cette rc est plutôt petite, sans toutes ces petites modifications habituelles… Je joins le résumé des mises-à-jour.
-rc7
La version -rc7 a été mise à disposition par Linus le samedi 14 juillet 2012.
Hé les gars, vous vous rappelez que les modifications se calmaient et ralentissaient, et que les développeurs du noyau étaient partis en vacances ?
Bon, on va devoir reparler de tout ça. Parce que la semaine passée je pensais que faire une -rc7 n'était pas tout à fait nécessaire, à part peut-être pour vérifier les derniers changements dans printk. Mais entre aujourd'hui et hier, j'ai reçu pleins de petites demandes de pull, et maintenant je me retrouve à livrer une -rc7 qui est plus grande que la -rc6.
C'est pas sympa, les gars. Pas cool.
Cela dit, il est vrai que la plupart de ces changements sont plutôt petits. Le patch de correction du calcul loadavg est plutôt gros, mais la majeure partie de ce patch est de l'ajout de commentaires (de longs commentaires).
Mais il y a la série de patchs d'Andrew, il y a les corrections dans media, les corrections un peu partout dans les systèmes embarqués, les corrections pour les powerpc, l'usb, le son, et j'en passe.
Alors d'accord ce n'est pas énorme, mais les modifications sont bien plus nombreuses que pour la -rc6. J'espérais le contraire.
Mais allez-y et testez. Assurez-vous que tout est bon. Parce que je ne voudrais vraiment pas avoir à faire une -rc8.
Les nouveautés
Algorithme CoDel
L'algorithme CoDel a été intégré dans le noyau Linux 3.5. Il constitue une réponse partielle au fameux problème du « bufferbloat » décrit dans la dépêche du noyau 3.3.
Pour résumer, il s'agit de changer le comportement de TCP afin d'éviter l'engorgement des buffers (les mémoires tampons) : quand un buffer est trop rempli par un fichier à envoyer (par exemple), les requêtes interactives (Web, SSH, etc.) sont ralenties car traitées après, il y a donc un équilibre à trouver dans le remplissage des buffers pour être efficace sans augmenter trop la latence..
Les algorithmes actuels utilisés dans TCP sur-utilisent ces buffers ce qui pénalise la latence : CoDel devrait corriger cela.
Notons quand même que tous les buffers induisent de la latence : ceux de l'application, de la pile TCP, de la carte réseau, de la box internet, des routeurs du FAI, etc., une modification de Linux est donc nécessaire mais pas forcément suffisante…
Pour plus d'information sur CoDel, voir cet article LWN.
x86
Le code gérant les exceptions pour l'architecture x86 a été entièrement revu.
C'est un grand nettoyage qui a été opéré sur ce code par David Daney et H. Peter Anvin avec comme but de permettre le tri de la table des exceptions lors de l'étape de compilation (avec l'option BUILDTIME_EXTABLE_SORT). De cette manière on peut gagner un peu de temps lors du boot puisque le tri est déjà fait et on supprime pas mal de vieux code:
Cette nouveauté a nécessité l'abstraction du protocole de la table des exceptions et a permis de retirer 20 ans de présupposés qui s'étaient accumulés au sujet du format de la table des exceptions. Le résultat de tous ces changements c'est que le code de gestion des exceptions x86 est maintenant très propre et moderne.
EDAC
Toujours dans le domaine de la gestion des erreurs, le développeur Mauro Carvalho Chehab a posté plusieurs patchs qui améliorent le sous-système EDAC (Error Detection And Correction). Il s'agit ici de gérer les erreurs qui peuvent survenir au sein des barrettes de RAM (mémoire vive) de nos machines. Jusqu'à présent ce code reposait sur des présupposés techniques qui n'ont plus lieu d'être avec les contrôleurs mémoire des processeurs modernes. Depuis l'introduction des technologies RAMBUS et FB-DIMM il est devenu nécessaire de repenser ce code sous peine d'obtenir des messages d'erreurs peu exploitables. Dans l'intervalle les pilotes des différents chipsets ont dû mentir au sous-système EDAC afin de pouvoir fonctionner correctement.
La refonte du code introduite dans le noyau 3.5, et qui modifie l'ABI interne, permet maintenant d'exposer au sous-système EDAC la technologie réelle qui est employée dans les barrettes mémoire. Les messages d'erreur sont plus explicites et ils permettent d'indiquer la zone physique touchée par l'erreur.
Bien entendu tous les pilotes de chipsets ont été convertis pour utiliser cette nouvelle version de l'ABI EDAC.
Btrfs
Dans son courriel récapitulatif, Chris Mason liste les principales nouveautés du noyau 3.5 concernant le système de fichiers Btrfs.
La gestion des erreurs s'améliore avec cette version. Stefan Behrens a introduit un moyen de compter les erreurs qui surviennent sur un disque, ce qui permet de mettre à l'écart ceux qui produisent trop d'erreurs, car il y a beaucoup de chances qu'ils soient défectueux. Les erreurs prises en compte sont les erreurs de lecture/écriture, les erreurs de CRC et les erreurs lors des vérifications des blocs de métadonnées.
Un bug qui pouvait provoquer de grosses latences a été corrigé. Le problème était que le writeback n'était pas considéré comme complet tant que les métadonnées sur les extends n'étaient pas écrites. Josef Bacik a utilisé un mécanisme existant qui surveille les insertions de métadonnées en attente pour terminer le writeback plus tôt.
Jan Schmidt a travaillé sur le suivi des blocs des btree lors du changement de propriétaire. Le code n'a, pour l'instant, pas d'utilité, mais le sera lorsque les fonctionnalités de quotas sur les sous-volumes et sur les envois/réceptions seront intégrées.
Ext4
La grosse nouveauté Ext4 de ce noyau est la possibilité de générer un code de redondance cyclique de type CRC-32 sur les métadonnées du système de fichiers. Les codes cycliques redondants permettent, en échange d'une consommation plus importante de l'espace disque, à la fois de détecter et de réparer les données corrompues.
Dans la pratique, lorsqu'une corruption est détectée il est possible de ne monter le système de fichiers qu'en lecture seule afin d'éviter des pertes de données sur les systèmes corrompus. Cette fonctionnalité s'active via tune2fs si vous ne voulez par reformater votre partition. Par contre, un noyau antérieur à cette version ne pourra, dans tous les cas, que monter le système de fichiers en lecture seule. De plus fsck est capable d'utiliser cette information pour réparer le système de fichiers.
Voir cet article LWN sur la surveillance des métadonnées via CRC-32.
NUMA
Depuis plusieurs années le noyau Linux offre l'option CONFIG_NUMA lors du build ce qui permet d'adapter l'ordonnanceur et l'allocation de mémoire afin de tirer partie des architectures NUMA.
L'architecture Numa est une architecture conçue pour des systèmes comprenant de nombreux cœurs de calcul sur un même processeur. Le problème avec ce genre d'architecture est comme toujours de garantir la cohérence des données contenue dans la mémoire. Il existe deux techniques différentes pour répondre à ce problème. L'architecture NUMA et SMP. Dans l'architecture SMP toute la mémoire est accessible par un seul et unique bus.
C'est une solution simple mais qui pose de nombreux problèmes d'accès concurrents et de cohérence du contenu de la mémoire. En effet il faut s'assurer qu'on ne modifie pas une donnée qui est elle-même en train d'être modifiée par un autre cœur.
Pour Numa on a au contraire un bus et une mémoire réservés par cœur de calcul (un node). Cette solution simplifie le problème de cohérence et d'accès mais introduit aussi un problème de distance quand un cœur a besoin d'une valeur calculée par un autre.
C'est le développeur Peter Zijlstra qui a entrepris de repenser complètement cette option en rendant le code plus souple et mieux adapté aux configurations matérielles sous-jacentes. Il n'y a plus de couches fixes et tout se base maintenant sur la fonction node_distance(), ce qui permet d'éliminer toutes les tables d'initialisations SD_NODE_INIT pour les diverses architectures.
Autosleep
Le projet de fusion des modifications d'Android dans le noyau Linux a commencé en décembre 2011. Le point le plus controversé concerne l'implémentation des "wakelocks" (que l'on pourrait traduire en "verrouillage en mode réveillé"). Normalement les machines sous Android se mettent en veille à la moindre occasion puisque c'est l'état par défaut du système. Le mécanisme "wakelocks" permet à certains logiciels de bloquer le passage en veille du système afin de pouvoir exécuter une tâche. Cette technique, qui empêche une application mal écrite de vider la batterie en consommant du CPU en permanence, est vivement critiquée par les développeurs du noyau, aussi bien sur la forme (la qualité du code d'Android) que sur le fond (l'intérêt de contourner le problème d'une application en complexifiant le noyau).
La fusion n'étant pas envisageable actuellement, Rafael Wysocki a élaboré une méthode alternative: autosleep. Elle se base sur un mécanisme mis en place dans le noyau 2.6.36 (oct. 2010) dans lequel un événement (comme l’appui sur un bouton) peut réveiller ou maintenir le système éveillé. Rafael a ajouté un fichier /sys/power/autosleep qui permet de spécifier une mise en veille automatique en mémoire ou sur disque en l'absence d'événement bloquant.
Il a également ajouté, à l’image d’Android, un journal des événements bloquants afin de connaître l’origine du maintien en activité ; et une interface permettant à une application disposant des droits nécessaires de bloquer la mise en veille pour un certain temps.
L’API est très similaire à celle d’Android dans le but de faciliter le fonctionnement d’une application Android sur un noyau ordinaire. Bien entendu personne ne sait si les développeurs d'Android vont chercher à tirer partie de cette nouvelle fonction en abandonnant progressivement wakelocks.
Voir cet article LWN sur autosleep.
Filtres Seccomp
Jusqu'à présent Linux n'offrait pas de moyen simple pour restreindre les appels systèmes utilisables par une application. C'est pourtant intéressant quand on veut compliquer autant que possible la vie d'un attaquant potentiel. Les développeurs de Chrome ont réussi à réaliser cette fonctionnalité sur Linux, mais leur solution est très compliquée, intégrant même un désassembleur x86 !
Le patch de Will Drewry introduisant le filtrage Seccomp des appels système via BPF devrait permettre de simplifier beaucoup les choses.
La technique repose donc, de façon étonnante, sur l'outil Berkeley Packet Filter qui est normalement utilisé pour filtrer les paquets réseau. Ici le mécanisme est réutilisé pour filtrer les appels systèmes en déclarant une liste blanche des appels autorisés. L'idée est que les développeurs d'applications, qui par définition connaissent parfaitement leur code, pourront créer un filtre Seccomp afin de déclarer la liste spécifique des appels autorisés pour leur application (voir la documentation).
S'il y a un accord sur l'utilité de filtrer les appels systèmes, il a tout de même fallu 3 ans avant qu'une solution soit acceptée par les développeurs et incluse dans le noyau. LinuxFr avait déjà parlé en début d'année de la saga des filtres seccomp.
Tracing
En regardant le courriel récapitulatif envoyé par Ingo Molnar on peut lister les améliorations du tracing incluses dans ce noyau 3.5.
On note tout d'abord que les possibilités de visualisation de l'outil perf ont été améliorées. Il est maintenant possible de faire des recherches ou de naviguer dans les résultats.
La technique IBS (Instruction-Based Sampling), qui est présente dans les derniers coeurs AMD, est maintenant exploitée par le noyau afin d'offrir des informations plus précises sur les cycles ou les micro-instructions utilisées lors de l'exécution d'un programme.
Enfin la nouveauté la plus importante est l'utilisation de la bibliothèque libtraceevent par l'outil perf. Cette bibliothèque permet de factoriser un certain nombre de lignes de code mais elle va surtout permettre à divers outils de se reposer sur elle dans le futur :
C'est le premier pas vers l'unification des outils de tracing et perf et cela offre également une bibliothèque de tracing sur laquelle les outils externes comme powertop peuvent s'appuyer.
User namespaces
Eric W. Biederman a écrit plusieurs patchs pour cette version du noyau afin de fiabiliser et d'améliorer la fonction d'isolation par conteneurs.
Puisque chaque UID peut être spécifique à un conteneur particulier, un nouveau type, nommé kuid_t est introduit afin d'identifier sans ambigüité les processus. L'isolation est plus propre entre l'hôte et les conteneurs qui sont hébérgés sur la machine. Ainsi l'utilisateur root sur un conteneur ne peut plus avoir un accès libre aux répertoires /proc/ et /sys/. Les capacités (capabilities) sont actives au sein de l'espace de nom du conteneur et on peut donc accorder sans risque ces capacités à l'utilisateur confiné dans le conteneur.
Enfin, d'après les tests effectués par Eric Biederman, les performances de ce sous-système rénové des conteneurs sont excellentes. Quand l'option n'est pas choisie à la compilation alors aucune dégradation n'est observée. Quand l'option est activée Eric à constaté un ralentissement extrêmement faible. Le test consistant à faire un milliard d'opérations stat passe de 156 secondes à 164 secondes sur son laptop.
Voir cet article LWN sur les améliorations de l'isolation par conteneurs.
Uprobes
Le patch uprobes, qui est utilisé pour placer des sondes dans les programmes en espace utilisateur, a enfin été inclus dans le noyau après des années d'attente. Il s'agit d'une sous-partie de SystemTap qui entre ainsi dans Linux pour faciliter le tracing des programmes.
Le message de commit de Srikar Dronamraju explique bien, avec force détails techniques, comment se fait ce placement de sondes tandis que ce second patch implémente l'interface avec perf.
Pour ce qui est d'expliquer l'utilité d'uprobes il faut se tourner vers ce message d'Ingo Molnar qui donne plusieurs exemples d'utilisation et qui souligne les bénéfices qu'apporte cette nouvelle fonction.
Amélioration du logging
La gestion du logging dans le noyau a évolué avec cette version 3.5.
Le but de ce patch est de passer d'un système de logging où on est orienté « flux d'octets » vers un système où on est orienté « enregistrement » (voir ce commit).
Pour le moment les messages peuvent facilement être corrompus sur leur chemin vers les logs. Par exemple, si il y a un buffer overflow, une partie des messages qui sont dans la mémoire tampon sera écrasée par les nouveaux messages.
De plus, les messages qui viennent de différents processeurs peuvent se mélanger, tout spécialement si un message de log est écrit par plusieurs coeurs.
Avec le patch de Kay Sievers le noyau place les logs dans un tampon afin d'éviter le mélange des différents flots de logs. Le patch apporte également des méta-informations comme le contexte spécifique du périphérique ou bien un numéro de séquence unique ce qui permet de flitrer plus efficacement les logs.
Au fil des versions candidates il s'est avéré que ce nouveau système de logging entrainant des conséquences inattendues sur la fonction printk().
Concrètement, quand on envoie un message dans le log en utilisant printk()
printk("mon début de super message de log ");
maSuperFonction1();
printk("la suite de mon super message de log ");
maSuperFonction2();
printk("la fin de mon super message de log. \n");
Les 3 appels à printk ci-dessus correspondent à une seule ligne dans syslog car tant qu'il n'y a pas de message se terminant par un retour chariot, le système de logging bufferise le message. Le problème avec cette technique c'est qu'avec le patch si quelque chose se passe mal le système de logging et le noyau se retrouvent bloqués.
Face à cette situation, les développeurs du noyau envisagent plusieurs solutions.
- changer tous les appels à printk pour qu'il se terminent tous par un retour chariot ;
- rajouter un printk_flush pour que les messages même partiels soient affichés si quelque chose se passe mal.
Le problème avec ces 2 solutions c'est qu'elles nécessitent de changer le code partout où le problème pourrait apparaître. Et l'expérience leur apprend que beaucoup de ces endroits ne peuvent être trouvés qu'en étant confronté au problème. Il y a donc trois solutions alternatives :
- ajouter une option pour activer/désactiver le buffering ;
- retirer ce patch de linux 3.5 ;
- retirer le buffering de printk.
Linus s'est montré particulièrement en faveur de la dernière option. Il pense qu'il n'y a aucun souci à générer les logs dans un buffer mais qu'en revanche le texte généré par printk devrait être immédiatement envoyé sur la console.
Kay Sievers a donc écrit un patch spécifique pour résoudre cet agaçant problème affectant printk. Ce nouvel épisode met simplement en lumière la difficulté de rajouter de la structure aux logs sans rendre la vie difficile aux développeurs.
Voir cet article LWN au sujet du logging dans le noyau.
TCP connection repair
L'intérêt de cette fonctionnalité est de permettre la migration d'un conteneur actif d'un hôte physique vers un autre. Le problème, dans ce cas-ci, est de conserver les connexions réseau actives et surtout les paquets TCP (les paquets UDP n'offrant aucune garantie de livraison, on peut se permettre de les supprimer sans aller à l'encontre du fonctionnement attendu). Avant cette version du noyau, la plupart des informations nécessaires pour cette migration pouvaient déjà être obtenues au travers de /proc et /sys.
Pavel Emelyanov a écrit un patch pour obtenir les informations manquantes et pouvoir les insérer dans un nouvel hôte. Il faut d'abord mettre les sockets que l'on veut migrer dans un état « repair mode » grâce à l'appel système setsockopt() avec le paramètre TCP_REPAIR. Pour cela, il faut la capacité CAP_NET_ADMIN et que la socket soit dans un état « connexion établie » ou « fermée ». Une fois cela effectué, on peut obtenir les paquets dans les fils d'attentes d'entrée et de sortie, mais aussi les paramètres négociés avec l'hôte distant comme les MSS (maximum segment size, taille maximum de segment). Si une socket est fermée alors qu'elle est en état « repair mode », elle est simplement supprimée sans aucune notification à l'hôte distant.
Pour transférer ces sockets sur le nouvel hôte physique, il faut d'abord les créer normalement puis les passer directement en état « repair mode ». On peut réécrire les files d'attente des paquets avec l'appel système sendmsg(), il faut aussi introduire les paramètres négociés avec l'hôte distant. Un point important est de réintroduire les numéros de séquence, ils se suivent, mais le premier est généralement généré aléatoirement, ce qui ne doit pas être le cas ici.
Une fois qu'on est à peu près dans le même état qu'avant la migration, on appelle la fonction connect() sur la socket, le système va alors mettre directement la socket dans l'état « connection établie » sans échanger de message avec l'hôte distant. Finalement, une sonde de fenêtre (window probe) est envoyée à l'hôte distant et le trafic réseau peut reprendre normalement sur cette socket sur le nouvel hôte physique.
Voir cet article LWN sur TCP connection repair.
Pilote graphique AMD
Fin des travaux sur le tampon de profondeur hiérarchique (Hiz pour les intimes) pour les cartes de la génération Evergreen (HD 5xxx) et Northern Islands (HD 6xxx). Bien entendu les améliorations de performances sont au rendez-vous.
Pilote graphique Intel
Intel n'est pas en reste puisque en plus de la moisson habituelle de nettoyage et d'amélioration du code existant, cette version voit l'intégration du code pour deux nouveaux processeurs graphique.
La première n'est autre qu'Haswell le successeur d'Ivy Bridge. Elle confirme la tendance d'Intel à intégrer le code le plus tôt possible dans le noyau pour avoir un support optimal à la sortie du produit.
La deuxième nouveauté est encore plus intéressante car elle annonce le retour de solution graphique maison pour les processeurs de type Atom. La génération suivante d'Atom se nommera Valley View et elle incorporera un coeur graphique proche de celui utilisé dans les processeurs Ivy Bridge. Les premiers patchs ont été ajoutés au noyau Linux 3.5 et le travail sera complété dans les versions suivantes. Cela signifie, joie et bonheur, que les coeurs graphiques PowerVR ne seront probablement plus utilisés sur les processeurs basse consommation d'Intel.
