Linux 7.3-rc2 Is Unusually Large—and Torvalds Joked That AI May Be Why

Linux 7.3-rc2 is not supposed to be the busiest point in a kernel cycle. The second release candidate usually follows the merge window with a comparatively quiet week while developers begin finding regressions. Instead, Linus Torvalds described 7.3-rc2 as a “full fat” release: it did not feel especially busy to him, but the resulting patch volume said otherwise. 1127

Torvalds did not identify one culprit. A late EDAC pull was part of the picture, but he characterized it as too small to explain the overall size. There were also filesystem fixes and a substantial DRM pull containing scattered fixes. In that context, his suggestion that maintainers might as well blame AI was a joke rather than a finding that an LLM directly caused rc2’s size. 11

What landed in Linux 7.3-rc2

The changes are broad rather than centered on a single emergency regression. Drivers make up most of the overall update, while tooling represents about one-fifth of the non-driver changes; filesystems, core kernel work, and networking also account for significant portions. 18

Notable fixes and cleanups include:

• Cache-aware scheduling misfit fixes for hybrid CPUs, intended to improve performance behavior. 9
• A tree-wide cleanup that moves more allocations from kmalloc() to kmalloc_obj(). 9
• Nouveau display fixes for NVIDIA Blackwell hardware. 9
• Changes that disable RandStruct security by default when Rust support and a Rust compiler toolchain are present. 9
• An EDAC change that missed the 7.3 merge window. 9
• Reported hardening work for the BPF verifier and fixes for scheduler regressions. 23

That combination helps explain why the release is large without supplying a single, simple explanation: multiple subsystems submitted valid maintenance work at once.

Why the AI remark matters—and what it does not mean

The joke has a real backdrop. Torvalds had previously described oversized late-cycle release candidates as part of a new normal associated with review by various AI tools. That is different from saying AI authored or caused every patch: the relevant effect is the growing volume of issues surfaced for human maintainers to evaluate and fix. 34

Greg Kroah-Hartman has separately warned that Linux 7.3 could be a “rough” cycle because AI/LLM activity is increasing the flow of bug reports and proposed patches. Some submissions are useful, but the review and triage burden remains with kernel developers, including for reports affecting old or rarely touched code. 32

The security trend illustrates the scale of that workload. Reports ahead of the 7.3 release cycle indicated that fixed CVEs per release had risen from roughly 500 across Linux 6.9 through 6.19 to more than 1,000 in 7.0 and more than 1,500 in 7.2; Linux 7.3 could approach 2,000 if the trend continues. That is a projection, not a final 7.3 total. 1234

A large rc2 follows a large rc1

The busy week arrives after an already oversized 7.3-rc1. Code-count reporting puts that tree at about 40.98 million lines, up from approximately 40.42 million in Linux 7.2—a gain of roughly 560,000 lines. Those totals include detected code, comments, blank lines, and other content in the source tree, so they should not be read as 40.98 million lines of executable code alone. 513

That context makes rc2’s volume more notable: the kernel is entering its test-and-fix phase after a merge window that substantially expanded an already very large project.

Could Linux 7.3 take longer to stabilize?

Linux 7.3-rc2 is a pre-release snapshot for testing, not the final stable kernel; kernel.org listed 7.3-rc2 on September 6, 2026. 30

A heavy early release candidate does not by itself mean the schedule will slip. But if substantial fixes and regressions keep arriving late in the cycle, maintainers can choose to issue additional release candidates. The trade-off is straightforward: more testing time lets important fixes settle before a stable release, whereas shipping on a fixed date with a fast-moving fix stream risks leaving less room for validation.

For Linux users and downstream distributions, the practical takeaway is not that 7.3 is inherently unsafe. It is that the cycle’s health will depend on whether the high volume turns into well-tested fixes or keeps generating late churn. The “blame AI” line captures that tension: automated analysis can uncover real defects, but it cannot remove the human work required to assess, integrate, and test every proposed change.