Linux 7.4-rc1 opens the largest merge window in kernel history, driven by AI
On November 1, 2026, Linus Torvalds released Linux 7.4-rc1 after a merge window of nearly 20,000 commits — a record he credits to the flood of AI-generated fixes. He calls it a healthier model in which AI patches join normal development instead of flooding the stabilization phase.
November 1, 2026. Linus Torvalds ships Linux 7.4-rc1 and, in his weekly state-of-the-kernel note, calls the just-closed cycle a “BIG merge window.” November 1, 2026. It came in at almost 20,000 commits, versus a typical 15,000. Phoronix rates it the largest in kernel history, with the source tree approaching 42 million lines. Why it matters: the driver is not new silicon — it is AI.
A record merge window, swollen by AI
The number is unambiguous. Torvalds reports a merge window of “almost 20,000 commits,” where recent cycles have hovered around 15,000. Roughly a third of the volume comes from a single subsystem: the AMDGPU driver’s register offsets and bit masks, the massive tables regenerated every time a new GPU generation lands.
But hardware is not what explains the gap. Torvalds writes it plainly: “I think the reason is the by now obvious one” — the reason is AI. “I’m *much* happier with the flood of AI triggered work going into the merge window than it showing up mainly as extra fixes during the -rc period.” In other words, he would rather see AI-generated fixes arrive early, inside the merge window, than endure a deluge of patches during stabilization.
That preference is not cosmetic. The -rc phase that follows the merge window exists to stabilize the tree, not to absorb new code. When AI fixes land in -rc, they muddy the sorting of regressions from improvements. When they land early, they get the full cycle’s worth of maturing.
# Check the running kernel from any mainstream distribution
uname -r # running kernel release
cat /proc/version # kernel version and compiler of the active build “A healthier model”: AI enters normal development
Torvalds states the shift outright. He hopes the unusual commit count “is a sign that the AI fixes are becoming more part of the ‘normal development’ than a flood of fixes that go into the whole stabilization phase.” His summary is a single phrase: “I think that’s a much healthier model.”
This is a change of tone from earlier cycles. For months, the kernel’s debate centered on the quality of patches produced by large language models — hallucinated function names, patches that compile but are semantically wrong, invented CVEs. Torvalds’s verdict does not deny those problems; it relocates them.
He hedges immediately. The cycle is “Large, and full of fixes for issues found by AI (and more and more the patches have been suggested by AI too, although they often get rewritten).” The parenthetical matters: the patches “often get rewritten.” AI finds and suggests; humans rewrite before merging. That is the exact boundary between tool and maintainer.
He offers a second, independent explanation. Many people expect 7.4 to be the next LTS kernel, “which is another independent reason why some releases tend larger than others.” A cycle expected to become LTS attracts more contributions, because it will live longer in production fleets.
What 7.4 actually carries
Beyond the AI debate, Linux 7.4 is dense. Phoronix catalogued it before rc1 even shipped.
On the AMD side, the AMDGPU driver enables HDMI 2.1 by default, with VRR and ALLM; AMD PerfOpt improves AI/LLM performance on integrated GPUs; Zen 6 preparation continues, including BTB CTX isolation. The NPU of the Ryzen AI Max 400 is finally recognized.
On the Apple and Google side, the first device trees arrive for the Apple M4 and A18 Pro, alongside support for the Tensor G5 in the Pixel 10. Qualcomm contributes support for several Snapdragon X2 laptops.
On filesystems and virtualization: EXT4 gains an iomap buffered I/O path, FUSE handles large folios, Intel adds a guard against denial-of-service inside TDX VMs, and Microsoft contributes a paravirtualized IOMMU driver for Hyper-V. The Google C Binder driver is removed in favor of its Rust rewrite.
One episode captures the ambivalence of AI in a single stroke. A new kernel taint meant to reduce AI-patch noise was reverted days later as a “crazy beast.” The AI-on-AI patch did not survive: the loop closed on itself.
AI’s less visible counterpart in this cycle is Rust. The removal of the Google C Binder driver in favor of its Rust rewrite is the quiet parallel to the AI story: where AI patches raise questions of correctness, Rust raises questions of language-level safety, turning whole classes of memory bug into compile errors rather than runtime exploits. The two trends pull in the same direction. AI multiplies the volume of code that needs review, while Rust shrinks the class of bugs that review must catch. Together they go some way toward explaining how the kernel can absorb nearly 20,000 commits in a single cycle without collapsing under its own weight.
Where these “AI-found” patches come from
“AI patches” covers several distinct streams that public debate rarely separates. The oldest is automated static analysis: Coccinelle, Sparse, and Smatch have flagged suspicious patterns in kernel code for years. What is new is that an LLM turns an analysis report into a first-draft fix, which a maintainer reworks before it is merged.
Fuzzing sits at the center. Syzkaller and its peers generate thousands of crashes; each one can become a candidate fix. AI steps in downstream, to propose the skeleton of the patch from the trace, and upstream, to suggest regression tests for the affected subsystem.
Torvalds’s caveat — “they often get rewritten” — lives exactly here. The AI produces a plausible starting point, rarely the final fix. Human labor does not disappear; it shifts from finding the bug to verifying and rewriting the proposal.
This pipeline also explains the volume. When a single subsystem — the AMDGPU registers — can account for a third of a merge window’s commits, it is because the mechanical generation of definitions has become routine, and AI slots into it without friction.
The LTS shadow and the timeline
If 7.4 does become LTS, enterprises will run it for years. That raises the stakes on testing: an LTS kernel must remain stable long after release.
The schedule is standard. The merge window closed on November 1, 2026 with rc1. Several release candidates follow over six to eight weeks, and the stable release is expected “right around the end of December,” per Phoronix. A year-end LTS would land at the right moment for distributions that anchor their long-term releases in the fall.
For an SRE or a security lead, the lesson is twofold. First, the AI code volume is not going to dry up; it is normalizing into the kernel’s flow. Second, human review remains the gate — Torvalds himself stresses the routine rewriting. Do not assume an “AI-suggested” patch is verified; it is verified, precisely, by a human, and that is what makes it mergeable.
Verdict. If you track mainline, test 7.4-rc1 on lab hardware, not production: the code volume is unprecedented. If you run a stable fleet, hold until the final release in December 2026 — and if 7.4 is confirmed LTS, treat its rollout as a maintenance milestone, not routine upkeep.
References
- Linus Torvalds — state of the kernel, November 1, 2026 (LKML)
- The Register — Linus Torvalds says Linux kernel is out of ‘stabilization phase’ and using ‘much healthier model’ for AI contributions
- Phoronix — Linux 7.4 Features Very Exciting With Radeon HDMI 2.1 By Default, AMD PerfOpt, Apple M4
- Phoronix — Linux 7.4 Merge Window Saw Nearly 20k Commits, Source Tree Approaching 42 Million Lines