Linux 7.3: 18.765 commits y récord de desarrolladores

Linux 7.3 ya está disponible: la release más grande en la historia del kernel

El kernel Linux 7.3 fue liberado y, según el anuncio recogido por LWN.net, es un récord en todos los frentes: 18.765 commits no-merge enviados por 3.021 desarrolladores, de los cuales 807 firmaban su primer parche al kernel. Para dimensionarlo, el ciclo anterior —Linux 7.2, liberado el 16 de agosto de 2026 según Linux Journal— había reunido 13.412 commits de 2.138 contribuyentes, con 404 primerizos. En un solo ciclo, el proyecto sumó más de 400 desarrolladores nuevos.

El anuncio llegó un domingo por la tarde y abre de inmediato el merge window de 7.4, que arranca el día siguiente. El responsable del kernel avisó además que estará de vacaciones familiares, así que su agenda será inusual por un tiempo. Para un founder, la lectura no es "salió una versión nueva del kernel": es que la capa donde corren tus contenedores, tus máquinas virtuales y tu factura de cloud acaba de recibir cambios que tocan latencia, memoria y aislamiento.

¿Qué cambia sched_ext y por qué importa si corres cargas en la nube?

El kernel 7.3 completa sched_ext, el mecanismo que permite que un cgroup tenga sus procesos gestionados por su propio planificador escrito en BPF. Según el changelog de KernelNewbies, distintos cgroups pueden usar sub-planificadores diferentes y tomar decisiones de scheduling distintas.

La release añade dos piezas que resuelven el problema clásico de "mi planificador experimental rompió el servidor": delegación de CPU por capacidades —el planificador padre otorga y revoca permisos por CPU a los hijos— y ejecución de rescate con ancho de banda limitado, que corre directamente las tareas varadas en lugar de dejar que el watchdog expulse el planificador completo. El resultado es una degradación acotada en vez de un fallo total.

Para quien opera infraestructura multi-tenant, esto abre la puerta a experimentar con políticas de scheduling por cliente sin arriesgar el nodo entero. También se suma al trabajo de scheduling de grupos orientado a sistemas grandes que menciona el anuncio original.

failfs y fchroot(): sandboxing sin contenedores

Otra novedad con impacto directo en seguridad es failfs, un pseudo-sistema de archivos cuyo criterio es "aquí no se soporta nada": toda operación que llega al filesystem falla con EOPNOTSUPP. Se combina con fchroot(2), una llamada al sistema que hace el chroot a partir de un file descriptor en lugar de una ruta, eliminando la ventana TOCTOU entre resolver el destino y cambiar la raíz.

Según KernelNewbies, un proceso puede mover su directorio raíz a failfs con fchroot(FD_FAILFS_ROOT) y, desde ese momento, toda ruta absoluta y todo symlink absoluto fallan. Combinado con fchdir(FD_FAILFS_ROOT), el proceso queda obligado a anclar cada búsqueda a un file descriptor explícito. El changelog señala que un usuario sin privilegios puede hacer chroot hacia failfs siempre que la tarea no tenga habilitados nuevos privilegios.

La misma release separa el estado de filesystem de los hilos del kernel y de PID 1, que ahora arrancan en un montaje nullfs aislado. Es una reducción de superficie de ataque silenciosa, pero relevante si vendes software que corre en máquinas de clientes.

Rendimiento: los números que sí mueven la aguja

Los datos del changelog de KernelNewbies para 7.3 son concretos:

• Btrfs: eliminar un retraso innecesario de 1 jiffy en modo no-SSD multiplica por 5 el throughput en cargas de logging; el fsync con la función no-holes es 5 veces más rápido.
• Ext4: la nueva ruta simple de I/O directo en iomap lleva a ext4 de 1,92 millones a 2,19 millones de IOPS en una carga de muestra.
• Memoria: reducir la contención de lru_lock baja el tiempo de espera total del lock más del 60%, y zsmalloc mejora hasta 1,83x en microbenchmarks.
• KSM: el arreglo del reverse-mapping baja el peor caso de retención del lock anon_vma de más de 500 ms a menos de 2 ms, evitando congelamientos de aplicación bajo presión de memoria.

Ninguno de estos cambios requiere que reescribas tu aplicación. Todos se traducen en menos latencia o más densidad por servidor si tu cuello de botella está en disco o en memoria.

Virtualización, almacenamiento y redes: lo que cambia en tu stack

• Working set de VMs: userfaultfd(2) ahora permite rastrear el conjunto de trabajo de la memoria de una máquina virtual invitada, para que el hipervisor identifique páginas calientes y evacue las frías a almacenamiento por capas o remoto.
• FUSE sobre io_uring: pools de buffers y zero-copy, con menos memoria requerida por el servidor FUSE.
• Bases de datos sobre block devices: el flag RWF_DONTCACHE permite abrir un dispositivo de bloque crudo y decidir por request si el dato pasa por page cache, sin los contras de Direct I/O.
• SMB/ksmbd: soporte opt-in para Apple Time Machine, cifrado SMB3 por share y cifrado en SMB Direct sobre RDMA.
• GPU: el controlador dmem del cgroup permite expulsar buffers no protegidos para hacer espacio, útil cuando varias aplicaciones compiten por VRAM en GPUs de gama baja.
• Redes: Big TCP para túneles UDP y soporte de binfmt_misc respaldado por BPF, que habilita binarios relocalizables sin trucos de patchelf.

¿Qué significa esto para tu startup?

Primero: no migres producción el lunes. Linux Journal recuerda que las distribuciones rolling release adoptan el kernel nuevo relativamente rápido, mientras que Ubuntu, Debian y las distribuciones enterprise suelen seguir con kernels soportados más antiguos y hacer backport de correcciones de seguridad y hardware. Si tu stack depende de una distro enterprise, tu equipo no va a ver 7.3 en producción pronto, y eso está bien.

Segundo: revisa si alguna mejora toca tu cuello de botella real. Si tu problema es I/O de base de datos, el salto de IOPS en ext4 y el flag RWFDONTCACHE son candidatos a medir con un benchmark propio. Si tu problema es memoria en servidores con contenedores, la reducción de contención de lru_lock y el tracking de working set de VMs son las líneas a testear. Si tu problema es aislamiento entre clientes, schedext por cgroup y failfs son las piezas nuevas.

Tercero: no confundas mainline con estable. Como explica kernel.org y recoge Linux Journal, los kernels mainline introducen funcionalidad nueva, mientras que las releases estables posteriores aportan correcciones que se hacen backport desde el desarrollo. Si necesitas soporte para hardware muy reciente, tienes argumentos para moverte antes; si no, esperar a que tu distro lo empaquete es la decisión racional.

Conclusión

El kernel 7.3 no es una release que vayas a instalar tú mismo, pero sí es la que va a llegar a tu infraestructura en los próximos meses a través de tu distribución o de tu proveedor de cloud. Los 807 desarrolladores primerizos y los 18.765 commits son la señal de fondo: el proyecto que sostiene casi todo el software que usas sigue creciendo a un ritmo que ningún equipo interno puede replicar. La jugada inteligente no es migrar rápido, sino saber qué mejora concreta te conviene y pedirla a tiempo a quien administra tus servidores.

Fuentes

• The 7.3 kernel has been released — LWN.net (fuente original)
• Linux 7.3 changelog — KernelNewbies
• Linux Kernel 7.2 Officially Released — Linux Journal