Debido a la forma en que se representa el tiempo en Linux, un número de 32 bits firmado no puede admitir tiempos posteriores al 19 de enero de 2038 después de las 3:14:07 UTC. Este problema del año 2038 (Y2038 o Y2K38) trata sobre la representación del tipo de datos de tiempo. La solución es usar marcas de tiempo de 64 bits.
Empecé a trabajar en el problema mientras trabajaba como pasante de Outreachy para el desarrollador del kernel Arnd Bergmann. Outreachy es un programa benévolo que ayuda a los nuevos programadores a entrar en el desarrollo de código abierto. Los mentores de los proyectos de kernel suelen ser desarrolladores de kernel experimentados como Arnd.
Elegí trabajar en el problema Y2038 porque me permitía tocar todos los subsistemas del núcleo, e incluso más que eso. El problema también involucra el espacio de usuario, la biblioteca C, POSIX y los estándares C. Descubrí que el problema es realmente acerca de las interfaces entre capas.
Más recursos de Linux
- Hoja de trucos de los comandos de Linux
- Hoja de trucos de comandos avanzados de Linux
- Curso en línea gratuito:Descripción general técnica de RHEL
- Hoja de trucos de red de Linux
- Hoja de trucos de SELinux
- Hoja de trucos de los comandos comunes de Linux
- ¿Qué son los contenedores de Linux?
- Nuestros últimos artículos sobre Linux
Resolver un problema en el núcleo rara vez implica una sola cosa; también implica la complejidad de las cosas interrelacionadas en el kernel (siempre se necesita una limpieza más antes del cambio) y las interacciones con la comunidad (especialmente cierto como recién llegado).
Una de las áreas que abordamos fue el sistema de archivos virtual (VFS). VFS es una capa de abstracción del sistema de archivos. Por lo tanto, incluso si algunos de los sistemas de archivos, como ext4, pueden representar marcas de tiempo posteriores al año 2038 en un sistema de 32 bits, no pueden hacerlo sin que la capa VFS los admita.
El cambio a VFS fue una de las series de parches que tomó más tiempo para obtener consenso y fusionarse.
Proponiendo una solución
El problema: La representación en el kernel de las marcas de tiempo del inodo estaba en struct timespec , que no es seguro para Y2038. La solución propuesta: Cambie la representación a struct timespec64 , que es seguro para Y2038.
Arnd publicó la primera versión de la serie en 2014. En ese momento, había algunos problemas abiertos y algunos comentarios sobre la adición de verificación de rango de marca de tiempo.
En enero de 2016, publiqué la primera solicitud de comentarios (RFC) para esto, preguntando si había alguna oposición al enfoque descrito anteriormente. Este no era un RFC típico para la comunidad del kernel. La carta de presentación de la serie explicaba el cambio propuesto y proporcionaba algunos ejemplos de cómo se realizarían los cambios. Hubo cierta confusión sobre lo que estábamos tratando de transmitir en la serie.
Publiqué otra serie (en realidad tres) para resolver el problema de tres maneras distintas. Esta fue una versión reducida de la serie anterior que abordó solo el problema central. Esto también fue atípico. El desarrollador del kernel, Thomas Gleixner, dijo que prefería ligeramente uno de los enfoques para resolver el problema, por lo que hicimos todos los parches de esta manera.
Pero tuvimos que deshacernos de algunas interfaces antiguas antes de poder hacer el cambio. Cuando publiqué una serie de esto, a Linus Torvalds no le gustó una de las interfaces (current_fs_time(sb) ) porque tomó el superbloque como argumento para acceder a la granularidad de la marca de tiempo. Pero las marcas de tiempo son realmente una característica del inodo, no del superbloque. Entonces, nos deshicimos de esta API.
Ahora la serie original tuvo que ser rehecha nuevamente. Hacer un parche del día de la bandera parecía un enfoque de fuerza bruta para el problema. Pero terminamos haciendo precisamente eso. Incluso fuimos un paso más allá usando un script de Coccinelle. Esto cambió más de 80 archivos. El reto era hacer los cambios rudimentarios para evitar retrocesos. Finalmente terminamos fusionando los parches en junio de 2018 y no hemos oído hablar de ninguna regresión por el cambio.
Al final de todo este ejercicio, nos deshicimos de tres API en el kernel, reorganizamos parte del manejo de marcas de tiempo del sistema de archivos, manejamos formatos de impresión para admitir marcas de tiempo más grandes, analizamos volcados de objetos de arquitectura de 32 bits y reescribimos al menos cinco versiones de la Serie desde cero. Y este fue solo uno de los problemas que resolvimos para el núcleo. Pero Y2038 ha sido uno de mis proyectos favoritos hasta ahora.
Deepa Dinamani presentará Cómo la búsqueda para evitar que se acabe el tiempo me ha llevado a todos los rincones del kernel de Linux en linux.conf.au, del 21 al 25 de enero en Christchurch, Nueva Zelanda.