Las claves en 30 segundos
- Récord absoluto. La ventana de integración de Linux 7.4, cerrada con la publicación de 7.4-rc1 el 1 de noviembre de 2026, suma 19.780 commits contando merges (18.591 sin ellos) según nuestro recuento sobre el git del kernel. Phoronix da 19.671. Torvalds habla de «casi 20.000 frente a los ~15.000 habituales».
- La IA, causa principal pero no única. Torvalds lo achaca al «aluvión de trabajo provocado por la IA», lo celebra porque entra en la ventana y no como correcciones durante las rc, y añade otro motivo: se espera que 7.4 sea la próxima LTS.
- Un tercio del parche es ruido. Son desplazamientos de registros y máscaras de bits de las GPU de AMD volcados en cabeceras.
- Los commits con la etiqueta
Assisted-by se han multiplicado por 2,4 respecto a la ventana de 7.3, y aun así se quedan cortos, porque el kernel dejó de exigir esa etiqueta a mitad de esta misma ventana.
- El aviso para hipervisores: una marca de taint nueva, pensada para frenar informes de fuzzing, habría marcado como contaminado el kernel de cualquier servidor que pase dispositivos PCIe a VMs. Se revirtió el 29 de octubre, antes de rc1.
Cada ventana de integración de Linux dura unas dos semanas: es el periodo en que Linus Torvalds acepta las novedades de los subsistemas antes de pasar a estabilizar con versiones candidatas. La de 7.4 ha sido la mayor de la historia, y la noticia, que adelantó AdministracionDeSistemas.com a partir de los datos de Phoronix, tiene más lectura para un administrador de sistemas que la cifra en sí. Hemos ido a las fuentes primarias, el anuncio de Torvalds y el propio repositorio del kernel, para contarla con datos propios.
Las cifras, contadas sobre el git del kernel
Para no depender de un único recuento, clonamos la historia del repositorio de Torvalds y contamos los commits entre cada versión estable y la rc1 siguiente, que es exactamente lo que abarca una ventana de integración:
| Ventana | Commits (con merges) | Sin merges | Con Assisted-by | % del total sin merges |
|---|
| 7.0 → 7.1-rc1 | 13.977 | 13.005 | 134 | 1,0 % |
| 7.1 → 7.2-rc1 | 14.396 | 13.413 | 706 | 5,3 % |
| 7.2 → 7.3-rc1 | 16.267 | 15.267 | 1.257 | 8,2 % |
| 7.3 → 7.4-rc1 | 19.780 | 18.591 | 3.008 | 16,2 % |
Recuento propio sobre las etiquetas v7.0 a v7.4-rc1 del repositorio de Linus Torvalds, 2 de noviembre de 2026. La etiqueta Assisted-by se buscó al inicio de línea, sin distinguir mayúsculas.
Las cifras de las ventanas anteriores coinciden con las de Phoronix (16.267 en 7.3, por ejemplo); en 7.4 la nuestra es algo más alta porque cuenta exactamente hasta la etiqueta de rc1. Durante más de una década, según la serie histórica de Phoronix desde Linux 3.1, las ventanas se movieron casi siempre entre 10.000 y 14.000 commits, con picos aislados como los 15.095 de 4.9 o los 16.203 de 6.7. En 2026 la pendiente cambió.
Tampoco es solo la ventana. Linux 7.3, publicada el 18 de octubre, fue la primera versión que pasa de 20.000 commits en el ciclo completo: 20.260 de la etiqueta de 7.2 a la de 7.3, según nuestro recuento y el de Phoronix. La 7.4 casi lo iguala antes de empezar a corregir.
Qué dice Torvalds, sin titulares
El anuncio de 7.4-rc1, publicado el domingo 1 de noviembre en la lista del kernel, merece leerse entero porque matiza bastante lo que se ha resumido después. Lo esencial:
- La IA como causa «obvia», y buena señal. Torvalds se dice «mucho más contento» de que el trabajo provocado por la IA entre en la ventana de integración que de verlo llegar como correcciones extra durante las rc. Espera que eso indique que esas correcciones ya son parte del desarrollo normal y no una avalancha sobre la fase de estabilización. Lo llama «un modelo mucho más sano», con una cautela: «ya veremos cómo van las rc».
- No es solo la IA. Una parte se debe a que la gente espera que 7.4 sea la próxima LTS, «otra razón independiente» por la que unas versiones crecen más que otras.
- El diff engaña. Un tercio entero del parche son desplazamientos de registros y máscaras de bits de GPU de AMD. «Ya hemos pasado por esto. Ignorad el ruido.»
- Por lo demás, normal. Grande y «lleno de correcciones de problemas encontrados por la IA», con cada vez más parches sugeridos por la IA, «aunque a menudo se reescriben». Sin las cabeceras de AMD, la mitad son controladores y el resto se reparte por arquitecturas, sistemas de ficheros, herramientas y núcleo (red, Rust, BPF, memoria).
Un dato que da idea del tamaño: el shortlog, el resumen de una línea por commit, ocupa 24.000 líneas y 1,2 MB, así que Torvalds ni lo adjunta.
La etiqueta Assisted-by, o por qué el 16 % se queda corto
El kernel introdujo en enero de 2026 una documentación para asistentes de programación (Documentation/process/coding-assistants.rst) que pedía añadir una línea Assisted-by a los parches hechos con ayuda de un modelo de lenguaje. En agosto se simplificó a un genérico Assisted-by: LLM. Y el 14 de octubre de 2026 Sasha Levin la eliminó, en un commit que entró en la rama principal el 20 de octubre, en plena ventana de 7.4.
El mensaje del commit explica bien por qué, y es la mejor advertencia sobre la tabla de arriba: solo un 10 % de los 18.533 commits de 7.3 hasta la rc7 llevaba la etiqueta, mientras que el uso real de los LLM está «mucho más extendido». Unos no conocían la regla, otros la omitían a propósito y pocos mantenedores la pedían, así que su ausencia no decía nada y su presencia, poco. En el Maintainers Summit de 2026 hubo un consenso «fuerte, aunque no unánime» para quitarla, y Greg Kroah-Hartman, que en julio defendió mantenerla, apoyó retirarla. Lo que no cambia: la IA no puede firmar el Signed-off-by del DCO, la persona que envía el parche sigue siendo responsable de él, y generated-content.rst sigue pidiendo transparencia sobre el uso de herramientas, ahora en la carta de presentación del parche.
Conclusión práctica: los 3.008 commits etiquetados son un mínimo, no una medida del peso de la IA. El recuento de commits mide actividad, no calidad ni funciones nuevas, y la atribución del récord a la IA es una interpretación de Torvalds y de Phoronix, razonable, pero sin un recuento separado detrás.
El susto que importa a quien virtualiza: TAINT_FORCED_BIND
El ciclo dejó un ejemplo muy claro de los efectos secundarios de este volumen. El 14 de septiembre Greg Kroah-Hartman escribió una opción, TAINT_FORCED_BIND, que marcaba el kernel como contaminado (tainted) en cuanto alguien escribía en los ficheros bind o unbind de sysfs para vincular o desvincular a mano un dispositivo de un controlador. El objetivo era frenar los informes de fuzzing de herramientas como syzbot, que asociaban dispositivos a controladores al azar y generaban errores y parches inútiles. La letra elegida para el taint era la «Y», porque el usuario estaría yeeting (lanzando sin miramientos) el dispositivo. Entró en la primera semana de la ventana.
El problema salta a la vista para cualquiera que administre hipervisores: VFIO usa justo ese mecanismo para quitarle un dispositivo PCIe al controlador del anfitrión y dárselo a vfio-pci, que es como se pasa una GPU o una NIC a una máquina virtual. Lo hemos comprobado en el código de Proxmox: la función pci_dev_bind_to_vfio de pve-common (PVE/SysFSTools.pm) escribe en unbind del controlador original y en bind de vfio-pci cada vez que arranca una VM con un dispositivo que no estaba ya reservado. Con esa opción activa, cualquier nodo con passthrough habría tenido el kernel marcado como contaminado por un uso completamente legítimo, con lo que eso supone a la hora de reportar fallos o pedir soporte.
Kroah-Hartman lo revirtió el 29 de octubre (entró en la rama principal el 30), antes de rc1. En el mensaje del revert describe VFIO como «una bestia loca», agradece con ironía que todo el mundo le explicara «lo equivocado que estaba» y deja la cuestión para después de 7.4, probablemente con una propuesta de Uwe Kleine-König basada en driver_override. También aclara que syzbot ya no hace esas asociaciones aleatorias, «aunque con esta locura de los LLM, nunca se sabe».
Dos lecturas para quien opera Proxmox con passthrough. La primera: si los dispositivos se reservan para vfio-pci desde el arranque (con options vfio-pci ids=... en modprobe), Proxmox no necesita hacer bind/unbind en cada arranque de VM, y ese camino es menos frágil ante cambios de este tipo. Lo explicamos en la guía de GPU passthrough en Proxmox con VFIO e IOMMU. La segunda, más general: con este ritmo de cambios, un comportamiento del que dependes puede romperse en mainline sin que nadie lo pretenda, y lo que te protege es no ejecutar mainline en producción y probar cada kernel nuevo antes en un nodo que no importe.
Lo que trae 7.4 para servidores
Más allá del récord, la ventana trae novedades con interés en un centro de datos. Las hemos sacado de los mensajes de merge de cada subsistema:
| Área | Novedad | Por qué importa |
|---|
| Intel TDX | Dynamic PAMT: los metadatos de TDX, que ocupaban ~0,4 % de la RAM física del host siempre, ahora se reservan por bloques de 2 MB según se usan | Activar TDX deja de costar memoria cuando apenas hay VMs confidenciales en el host |
| Intel TDX | Tamaño dinámico de los quotes de atestación | Los buffers fijos de 128 KB se quedaban cortos para criptografía poscuántica |
| AMD SEV-SNP | Soporte de la instrucción RMPOPT e informe en sysfs de las funciones SEV activas | Menos sobrecarga al verificar la propiedad de páginas en VMs confidenciales |
| VFIO | Seguimiento de mapeos no reservados para acelerar el desmontaje | Corrige un soft lockup con GPU de mucha memoria al apagar la VM |
| KVM arm64 | Aislamiento de estado en pKVM, primeros pasos hacia GICv5 SMP y preparación para Arm CCA | Base de la virtualización confidencial en Arm, que importa con Proxmox VE en arm64 |
| ext4 | E/S con búfer sobre iomap, opcional con la opción de montaje buffered_iomap | Mejoras notables en escrituras grandes, con limitaciones (sin cifrado, verity ni data=journal) |
| AMD | Soporte para Zen 6 y PerfOpt en la IOMMU para GPU integradas | Habilitación de la próxima generación de EPYC y Ryzen |
El resto (HDMI 2.1 por defecto en AMDGPU, portátiles con Snapdragon X2, soporte básico de Apple M4, Google Tensor G5) tiene menos que ver con servidores.
Calendario y LTS: lo que todavía no es oficial
Con siete u ocho versiones candidatas, que es el ritmo habitual, la versión final llegaría hacia el 20 de diciembre de 2026, según el cálculo de Phoronix. Y casi todo el mundo espera que sea la LTS de 2026: la tradición es que la última versión del año reciba soporte extendido, y hoy la lista de kernel.org termina en la 6.18, la LTS de 2025, con 6.12, 6.6, 6.1, 5.15 y 5.10 detrás. Pero las dos cosas son expectativas: la fecha depende de cómo vayan las rc, y la designación LTS la confirman los mantenedores de las ramas estables cuando la versión ya está publicada.
Para quien gestiona Proxmox, conviene recordar un matiz que explicamos al hablar de Linux 7.2: Proxmox no sigue las LTS de kernel.org. Proxmox VE 9.2 y Proxmox Backup Server 4.2 llevan un kernel 7.0 con parches propios, mantenido por Proxmox, y las novedades útiles de versiones posteriores llegan por backport o con una versión nueva de Proxmox. Que 7.4 sea LTS importa sobre todo a las distribuciones generalistas y a los dispositivos con ciclos de vida largos.
Qué hacer con todo esto
El récord en sí no exige tocar nada. Lo que anticipa, sí:
- Más correcciones significa más actualizaciones estables y más CVE. Si el volumen de parches encontrados con IA se mantiene, también crecerá el ritmo de versiones estables y de avisos que llegan a las distribuciones. Conviene tener el parcheo del kernel automatizado y medido, y valorar mecanismos para reiniciar menos, como los que contamos en KHO y LUO: actualizar el kernel sin apagar las cargas.
- Nada de rc en producción. Las versiones candidatas son para pruebas. En un clúster, el kernel nuevo se prueba primero en un nodo sin cargas críticas, migrando las VMs en caliente, y solo después se extiende.
- Revisar dependencias de comportamientos raros. El episodio de
TAINT_FORCED_BIND muestra que lo que para un desarrollador es una interfaz de depuración, para un hipervisor es la ruta normal. Si tu operación depende de algo así (passthrough, bind/unbind, parámetros de arranque exóticos), merece estar documentado y probado en cada actualización. Lo cubrimos dentro de la línea base de hardening para Debian y Ubuntu.
Preguntas frecuentes
¿Cuántos commits ha tenido la ventana de integración de Linux 7.4?
Según nuestro recuento sobre el repositorio del kernel, 19.780 contando merges y 18.591 sin ellos, entre la etiqueta de 7.3 y la de 7.4-rc1. Phoronix da 19.671 y Torvalds habla de «casi 20.000». En cualquier caso, es la mayor ventana de la historia del kernel.
¿El récord se debe solo a la inteligencia artificial?
No del todo. Torvalds cree que el trabajo provocado por la IA es la causa principal, pero apunta también a que se espera que 7.4 sea LTS. Además, un tercio del tamaño del parche son cabeceras de registros de GPU de AMD.
¿Cuántos commits de 7.4 se han hecho con IA?
No se sabe. 3.008 commits llevan la etiqueta Assisted-by, 2,4 veces más que en la ventana de 7.3, pero la etiqueta nunca se cumplió del todo y el kernel dejó de exigirla el 20 de octubre. Es un mínimo, no una medida.
¿Afecta el cambio de TAINT_FORCED_BIND a mis servidores con passthrough?
No. Se integró y se revirtió dentro de la misma ventana, antes de 7.4-rc1, así que no llega a ninguna versión publicada. El propio Kroah-Hartman lo dejó para después de 7.4, previsiblemente con otro enfoque.
¿Cuándo sale Linux 7.4 y será LTS?
La rc1 salió el 1 de noviembre de 2026. Con el ritmo habitual, la versión final llegaría hacia el 20 de diciembre, y se espera que sea la LTS de 2026, pero ninguna de las dos cosas es oficial todavía.
Fuentes
- AdministracionDeSistemas.com, «Linux 7.4 bate el récord de commits empujado por la IA» (2 de noviembre de 2026): administraciondesistemas.com/linux-7-4-merge-window-record-commits-ia.
- Linus Torvalds, «Linux 7.4-rc1», anuncio en la lista del kernel (1 de noviembre de 2026), archivado en LWN: lwn.net/Articles/1104653.
- Phoronix, «The Linux 7.4 Merge Window Is Easily The Largest In Kernel History»: phoronix.com/news/Linux-7.4-Massive-Window.
- Phoronix, «Linux 7.4-rc1 Released»: phoronix.com/news/Linux-7.4-rc1.
- XenoSpectrum, recuento de commits con
Assisted-by en Linux 7.4: xenospectrum.com/en/linux-74-ai-assisted-commits.
- Repositorio de Linux, comparación entre 7.3 y 7.4-rc1: github.com/torvalds/linux/compare/v7.3…v7.4-rc1. Commits citados: revert de
TAINT_FORCED_BIND (a287f97d42) y «docs: remove Assisted-by references» (1e035297ff).
- kernel.org, versiones activas y ramas LTS: kernel.org/category/releases.html.
- Proxmox,
pve-common, src/PVE/SysFSTools.pm (función pci_dev_bind_to_vfio): git.proxmox.com/?p=pve-common.git.
- Recuento propio de commits por ventana de integración sobre el repositorio de Linus Torvalds, 2 de noviembre de 2026.
¿Te preocupa seguir el ritmo de parches del kernel en un clúster que no puede pararse? En Cloud Privado operamos Proxmox VE en centros de datos en España como servicio gestionado, con actualizaciones probadas antes de llegar a tus nodos. Si quieres revisarlo, hablemos.
