GNU/Linux >> LINUX-Kenntnisse >  >> Linux

Lösen des Jahr-2038-Problems im Linux-Kernel

Aufgrund der Zeitdarstellung in Linux kann eine signierte 32-Bit-Zahl keine Zeiten nach dem 19. Januar 2038 nach 3:14:07 UTC unterstützen. Bei diesem Jahr 2038-Problem (Y2038 oder Y2K38) geht es um die Darstellung des Zeitdatentyps. Die Lösung ist die Verwendung von 64-Bit-Zeitstempeln.

Ich begann mit der Arbeit an dem Problem, als ich als Outreachy-Praktikant für den Kernel-Entwickler Arnd Bergmann arbeitete. Outreachy ist ein wohlwollendes Programm, das neuen Programmierern hilft, in die Open-Source-Entwicklung einzusteigen. Die Mentoren für die Kernel-Projekte sind in der Regel erfahrene Kernel-Entwickler wie Arnd.

Ich habe mich für das Y2038-Problem entschieden, weil ich damit alle Subsysteme im Kernel berühren konnte – und noch mehr. Das Problem betrifft auch den Benutzerbereich, die C-Bibliothek, POSIX und C-Standards. Ich habe festgestellt, dass das Problem wirklich an Schnittstellen zwischen Schichten liegt.

Weitere Linux-Ressourcen

  • Spickzettel für Linux-Befehle
  • Spickzettel für fortgeschrittene Linux-Befehle
  • Kostenloser Online-Kurs:RHEL Technical Overview
  • Spickzettel für Linux-Netzwerke
  • SELinux-Spickzettel
  • Spickzettel für allgemeine Linux-Befehle
  • Was sind Linux-Container?
  • Unsere neuesten Linux-Artikel

Das Lösen eines Problems im Kernel beinhaltet selten nur eine Sache; es beinhaltet auch die Komplexität miteinander verbundener Dinge im Kernel (vor der Änderung ist immer eine weitere Bereinigung erforderlich) und Interaktionen mit der Community (besonders als Neuling).

Einer der Bereiche, die wir in Angriff genommen haben, war das virtuelle Dateisystem (VFS). VFS ist eine Dateisystem-Abstraktionsschicht. Selbst wenn einige der Dateisysteme, wie ext4, Zeitstempel über das Jahr 2038 hinaus auf einem 32-Bit-System darstellen können, können sie dies nicht ohne die VFS-Schicht, die sie unterstützt.

Der Wechsel zu VFS war eine der Patch-Serien, die am längsten brauchten, um einen Konsens zu erzielen und integriert zu werden.

Eine Lösung vorschlagen

Das Problem: Die In-Kernel-Darstellung von Inode-Zeitstempeln war in struct timepec , was nicht Y2038 sicher ist. Die vorgeschlagene Lösung: Ändern Sie die Darstellung in struct timepec64 , was Y2038-sicher ist.

Die erste Version der Serie wurde 2014 von Arnd gepostet. Damals gab es einige offene Probleme und einige Rückmeldungen zum Hinzufügen der Zeitstempel-Bereichsprüfung.

Im Januar 2016 habe ich dazu den ersten Request for Comments (RFC) gepostet und gefragt, ob es Widerstände gegen das oben beschriebene Vorgehen gebe. Dies war kein typischer RFC für die Kernel-Community. Das Serienanschreiben erläuterte die vorgeschlagene Änderung und lieferte einige Beispiele dafür, wie die Änderungen durchgeführt werden würden. Es gab einige Verwirrung darüber, was wir in der Serie vermitteln wollten.

Ich habe eine weitere Serie (eigentlich drei) veröffentlicht, um das Problem auf drei verschiedene Arten zu lösen. Dies war eine abgespeckte Version der früheren Serie, die nur das Kernproblem ansprach. Auch das war untypisch. Kernel-Entwickler Thomas Gleixner sagte, dass er einen der Ansätze zur Lösung des Problems etwas bevorzuge, also haben wir alle Patches auf diese Weise erstellt.

Aber wir mussten einige alte Zeitschnittstellen loswerden, bevor wir die Änderung vornehmen konnten. Als ich eine Reihe davon gepostet habe, gefiel Linus Torvalds eine der Schnittstellen (current_fs_time(sb)) nicht ), da der Superblock als Argument für den Zugriff auf die Zeitstempelgranularität verwendet wurde. Aber die Zeitstempel sind wirklich ein Merkmal des Inodes, nicht des Superblocks. Also haben wir diese API entfernt.

Nun musste die Originalserie noch einmal überarbeitet werden. Einen Flaggentag-Patch zu machen, schien eine brutale Herangehensweise an das Problem zu sein. Aber am Ende haben wir genau das getan. Wir sind sogar noch einen Schritt weiter gegangen, indem wir ein Coccinelle-Skript verwendet haben. Dadurch wurden mehr als 80 Dateien geändert. Die Herausforderung bestand darin, die Änderungen rudimentär vorzunehmen, um Regressionen zu vermeiden. Wir haben die Patches schließlich im Juni 2018 zusammengeführt und haben noch nichts von Regressionen durch die Änderung gehört.

Am Ende dieser ganzen Übung haben wir drei In-Kernel-APIs losgeworden, einige der Handhabung von Dateisystem-Zeitstempeln neu angeordnet, Druckformate gehandhabt, um größere Zeitstempel zu unterstützen, 32-Bit-Architektur-Objekt-Dumps analysiert und mindestens fünf Versionen von neu geschrieben Serie von Grund auf neu. Und das war nur eines der Probleme, die wir für den Kernel gelöst haben. Aber Y2038 war bisher eines meiner Lieblingsprojekte.


Deepa Dinamani wird auf der linux.conf.au vom 21. bis 25. Januar in Christchurch, Neuseeland, präsentieren, wie die Suche nach dem Verhindern, dass die Zeit abläuft, mich in alle Ecken des Linux-Kernels geführt hat.


Linux
  1. Linux – Teilnahme an der Kernel-Mailingliste?

  2. Linux – Warum kann der Kernel Init nicht ausführen?

  3. Linux – Proprietäre oder geschlossene Teile des Kernels?

  4. Was ist die aktuelle Linux-Kernelquelle?

  5. Debuggen der Linux-I/O-Latenz

Wie ich Tetris auf dem Mainframe spiele

Wie der Linux-Kernel mit Interrupts umgeht

Meine Linux-Story:Linux lernen in den 90ern

Wie der Linux-Desktop gewachsen ist

So überprüfen Sie die Kernel-Version in Linux

Das Jahr der Linux-Unzufriedenheit