En raison de la façon dont l'heure est représentée sous Linux, un nombre 32 bits signé ne peut pas prendre en charge les heures au-delà du 19 janvier 2038 après 3:14:07 UTC. Ce problème de l'année 2038 (Y2038 ou Y2K38) concerne la représentation du type de données temporelles. La solution consiste à utiliser des horodatages 64 bits.
J'ai commencé à travailler sur le problème alors que je travaillais comme stagiaire Outreachy pour le développeur du noyau Arnd Bergmann. Outreachy est un programme bienveillant qui aide les nouveaux programmeurs à se lancer dans le développement open source. Les mentors pour les projets du noyau sont généralement des développeurs de noyau expérimentés comme Arnd.
J'ai choisi de travailler sur le problème Y2038 parce qu'il me permettait de toucher à tous les sous-systèmes du noyau, et même plus que cela. Le problème implique également l'espace utilisateur, la bibliothèque C, POSIX et les normes C. J'ai découvert que le problème concernait vraiment les interfaces entre les couches.
Plus de ressources Linux
- Aide-mémoire des commandes Linux
- Aide-mémoire des commandes Linux avancées
- Cours en ligne gratuit :Présentation technique de RHEL
- Aide-mémoire sur le réseau Linux
- Aide-mémoire SELinux
- Aide-mémoire sur les commandes courantes de Linux
- Que sont les conteneurs Linux ?
- Nos derniers articles Linux
Résoudre un problème dans le noyau implique rarement une seule chose; cela implique également la complexité des choses interdépendantes dans le noyau (il y a toujours un nettoyage supplémentaire nécessaire avant le changement) et les interactions avec la communauté (particulièrement vrai en tant que nouveau venu).
L'un des domaines que nous avons abordés était le système de fichiers virtuel (VFS). VFS est une couche d'abstraction du système de fichiers. Ainsi, même si certains systèmes de fichiers, comme ext4, peuvent représenter des horodatages au-delà de l'année 2038 sur un système 32 bits, ils ne peuvent pas le faire sans la couche VFS qui les prend en charge.
Le changement vers VFS a été l'une des séries de correctifs qui a pris le plus de temps pour obtenir un consensus et être fusionné.
Proposer une solution
Le problème : La représentation dans le noyau des horodatages d'inode était dans struct timespec , qui n'est pas sûr Y2038. La solution proposée : Modifiez la représentation en struct timespec64 , qui est sûr pour Y2038.
La première version de la série a été publiée par Arnd en 2014. À l'époque, il y avait quelques problèmes ouverts et des commentaires sur l'ajout de la vérification de la plage d'horodatage.
En janvier 2016, j'ai posté la première demande de commentaires (RFC) à ce sujet, demandant s'il y avait une opposition à l'approche décrite ci-dessus. Ce n'était pas une RFC typique pour la communauté du noyau. La lettre d'accompagnement de la série expliquait le changement proposé et fournissait quelques exemples de la façon dont les changements seraient apportés. Il y avait une certaine confusion sur ce que nous essayions de faire passer dans la série.
J'ai posté une autre série (en fait trois) pour résoudre le problème de trois manières distinctes. Il s'agissait d'une version allégée de la série précédente qui n'abordait que le problème principal. C'était aussi atypique. Le développeur du noyau, Thomas Gleixner, a déclaré qu'il préférait légèrement l'une des approches pour résoudre le problème. Tous les correctifs ont donc été créés de cette manière.
Mais nous avons dû nous débarrasser de certaines interfaces désuètes avant de pouvoir effectuer le changement. Quand j'ai posté une série de ceci, Linus Torvalds n'a pas aimé l'une des interfaces (current_fs_time(sb) ) car il a pris le superbloc comme argument pour accéder à la granularité de l'horodatage. Mais les horodatages sont vraiment une caractéristique de l'inode, pas du superbloc. Nous nous sommes donc débarrassés de cette API.
Maintenant, la série originale devait être refaite à nouveau. Faire un patch du jour du drapeau semblait être une approche brutale du problème. Mais nous avons fini par faire exactement cela. Nous sommes même allés plus loin en utilisant un script Coccinelle. Cela a modifié plus de 80 fichiers. Le défi était de rendre les changements rudimentaires pour éviter les régressions. Nous avons finalement fusionné les correctifs en juin 2018 et n'avons entendu parler d'aucune régression suite à ce changement.
À la fin de cet exercice, nous nous sommes débarrassés de trois API dans le noyau, réorganisé une partie de la gestion de l'horodatage du système de fichiers, géré les formats d'impression pour prendre en charge des horodatages plus grands, analysé les vidages d'objets d'architecture 32 bits et réécrit au moins cinq versions du série à partir de zéro. Et ce n'était qu'un des problèmes que nous avons résolus pour le noyau. Mais Y2038 a été l'un de mes projets préférés jusqu'à présent.
Deepa Dinamani présentera Comment la quête pour éviter que le temps ne s'épuise m'a conduit à tous les coins du noyau Linux sur linux.conf.au, du 21 au 25 janvier à Christchurch, en Nouvelle-Zélande.