On September 6, 2026, Linus Torvalds released Linux 7.3-rc2, describing it as a "full fat" rc2. In what should have been the quietest week right after the merge window closed, 681 commits piled up between the rc1 tag and the rc2 tag. Torvalds himself didn't pin the cause on any single thing, listing a late EDAC pull that had been forgotten during the merge window, fixes from multiple filesystems, and an influx from drm and networking — before closing with a joke: "Might just be random, but I guess everybody will blame AI for it anyway." He capped it off with a winking emoticon. The Register ran that line as its headline, but what the git tag diff actually confirms is only the anomalous scale — it doesn't identify the cause.
Recounting what's inside the "full fat" rc2
Counting commits from the rc1 tag to the rc2 tag under identical conditions across all 16 cycles since v6.8, 7.3-rc2's 681 commits comes out as the maximum. This result holds both endpoints fixed at release-candidate tags and includes merge commits in the count. The length of the intervals also falls within a narrow range — 6.9 to 7.8 days — so the difference can't be explained away by differing day counts.
データを表で見る
| Commit count (commits) | |
|---|---|
| 6.8 | 391 |
| 6.9 | 390 |
| 6.10 | 323 |
| 6.11 | 336 |
| 6.12 | 382 |
| 6.13 | 424 |
| 6.14 | 277 |
| 6.15 | 339 |
| 6.16 | 240 |
| 6.17 | 225 |
| 6.18 | 363 |
| 6.19 | 342 |
| 7.0 | 434 |
| 7.1 | 475 |
| 7.2 | 433 |
| 7.3 | 681 |
The second-highest count across the 16 cycles is 7.1-rc2's 475 commits, which 7.3-rc2 exceeds by 43.4%. The average for the twelve 6.x-era cycles — v6.8 through v6.19 — is 336.0 commits, meaning 681 is roughly 2.03 times that figure. Torvalds' own remark that "it didn't feel like a busy rc2, but it obviously was" checks out, at least in terms of sheer commit volume.
But this jump didn't appear out of nowhere at rc2. The average across the three cycles since the major version moved to 7.x (v7.0 through v7.2) already sits at 447.3 commits, 33.1% above the 6.x average. Even against that 7.x baseline, this cycle's 681 commits is a further 1.52x. In other words, 7.3-rc2's anomaly reads as a cycle-specific spike stacked on top of a floor that had already been gradually rising.
The limits of this counting method are worth noting too. Commit count is just a count — it doesn't capture the size of each change. How much the lines changed per commit differs across cycles, and that's invisible in this comparison. The comparison set is also limited to the 16 cycles since v6.8; there's no claim that this is the largest going further back than that.
The 7.x average of 447.3 commits is itself based on only three cycles, making it sensitive to swings in any individual cycle. Nothing in this calculation ties the rise in the floor from the 6.x era to the 7.x era to the spread of AI tools — a version number change has no direct causal link to a change in development volume.
What Torvalds cited as causes — and what he didn't
In the announcement text, Torvalds listed three things as contributing to the scale: a delayed EDAC pull that had been forgotten during the merge window, fixes from multiple filesystems, and a sizeable drm pull containing scattered fixes. He also named networking and BPF fixes, along with several driver trees, as contributing factors. He noted the EDAC pull was "fairly small," and at no point did he single out any one factor as the main culprit.
He also gave a concrete breakdown of the changes. Tooling accounted for roughly 20% of the total patches, driven mainly by sched_ext and selftests. Setting drivers aside, tooling was the single largest source of change, followed by filesystems, the core kernel, and networking. The word "AI" appears nowhere in this breakdown.
He then wrapped up his search for a cause: "Nothing particularly odd stands out, although it's a bit unusual for this point in the rc cycle... and there isn't a single cause either." AI only shows up in the sentence that follows: "Might just be random, but I guess everybody will blame AI for it anyway, whether that's really the cause or not, because it's an easy target to blame." Read together with the winking emoticon at the end, this comes across less as an accusation and more as self-deprecating humor about not being able to pin down a cause.
A week earlier, there had been a similarly toned preview. In the 7.3-rc1 announcement on August 30, Torvalds wrote, "let's hope the rest goes smoothly, small, and uneventfully. Then again, what am I saying — it's probably not going to be small, but hope is free." That was a forecast for the entire 7.3 cycle, not just rc2, and in the same announcement he explained that roughly a third of rc1's total patches consisted solely of AMD DCN6 register headers and code for a new generation of hardware. Even before he named AI, Torvalds himself had already sensed this cycle wasn't going to wrap up lightly.
615, 681, or 2,000 — which number is right?
For this same rc2, more than one figure is circulating. The change list attached to Torvalds' announcement shows 292 people and 615 commits; the repository's tag-to-tag diff shows 681 commits; and some aggregator sites reported "roughly 2,000 commits from 694 contributors." That's a gap of about 3x in commit count and about 2.4x in contributor count.
The gap between 615 and 681 has a clear explanation. The change list attached to the announcement only enumerates non-merge commits — merge commits that pull in subsystem trees aren't counted. The tag-to-tag diff, on the other hand, counts every commit unique to the rc2 side, merges included. The 66-commit difference corresponds to merge commits, giving a rough sense of how many pulls Torvalds took in that week. Both counting methods are valid — but writing "commit count" without specifying what was actually counted means the same release candidate ends up with different numbers floating around.
The figure of 2,000 doesn't have that kind of explanation. The site in question doesn't specify its counting method, and it's possible the number mixes in a cumulative count including rc1, or figures drawn from linux-next. But numbers of unclear origin only inflate the impression of scale each time they get cited. In discussions about the volume of Linux kernel development — especially when the conversation turns to AI-driven increases — it's worth checking exactly which tags a number spans, and whether merges were included.
How much of the maintainer burden do the numbers actually show?
Five days before rc2, on September 1, 2026, Greg Kroah-Hartman warned that 7.3 was shaping up to be a tough cycle. According to his own post, the USB "todo" mailbox had a backlog of 1,732 messages, and even after excluding obvious fixes and duplicates, 1,094 remained. "There's no sign of things settling down in the world of kernel development — not even in older subsystems that are supposed to be 'stable,'" he wrote.
Quality-side metrics are moving too. According to Kroah-Hartman's presentation materials for Kernel Recipes 2026, CVE counts per release averaged around 500 over the 6.9-to-6.19 period, but exceeded 1,000 starting with 7.0 and topped 1,500 with 7.2. However, according to Phoronix, most of these are low-priority vulnerabilities in old or unused drivers. A rising count doesn't by itself mean quality is deteriorating.
There are numbers on the machine-detection side as well. Sashiko, an AI review platform Google kernel engineer Roman Gushchin published in March 2026, detected known bugs in 53.6% of the most recent 1,000 upstream commits tagged with "Fixed," according to materials from its developers — and all of those had been missed by human review. Gushchin states the false-positive rate stays under 20%. Both figures come from the presenter's own materials and self-reporting, without independent verification. They're suggestive of usefulness, but they don't tell us how much of rc2's 681 commits AI review actually produced.
In short: numbers demonstrating that the workload has grown, and numbers identifying the cause of that growth, are two different things. The former have come from multiple sources; the latter has come from no one.
What the kernel actually changed wasn't the debate over causes, but a procedure
While the debate over causes remains unresolved, the kernel has moved to tighten submission etiquette instead. The document governing AI-assisted submissions, Documentation/process/coding-assistants.rst, was added by Sasha Levin on December 23, 2025, and has been revised three times in 2026. On July 1, Christian Brauner simplified the attribution wording; on July 2, Lorenzo Stoakes added links to related documentation; and on August 2, Willy Tarreau added important steps for bug-hunting. These were folded into 7.3 via the docs-7.3 merge on August 20 — a product of this very cycle.
The procedure the document lays out is specific. Submissions assisted by AI are recommended to carry an Assisted-by: LLM [TOOL1] [TOOL2] tag. At the same time, one rule is not being relaxed: "AI agents must not add Signed-off-by tags. Only a human can legally attest to the DCO (Developer Certificate of Origin)."
For bug reports, anything non-trivial is required to be validated through reproduction steps. The document also calls for build and test execution, passing checkpatch.pl, and using get_maintainer.pl, and requires that any step that couldn't be performed be explicitly disclosed. The stated rationale is that maintainers' time is being consumed excessively analyzing unverified reports and untested fixes.
This design, which anchors accountability firmly to humans, does nothing to stop the sheer volume from growing. What it stops is unverified material flowing in disguised as something already verified. For users in Japan, this distinction matters most when adopting LTS (Long Term Support) kernels. For embedded devices and domestic server infrastructure running a kernel long-term, the task of sorting through which of the more than 1,000 CVEs per release actually apply to one's own configuration grows heavier. If the rising count skews toward low-priority driver vulnerabilities, that changes the estimated cost of doing that triage.
Given that rc1 landed on August 30 and cycles typically run seven to eight weeks, the official 7.3 release is expected sometime from mid- to late October. Whether the commit counts for rc3 and beyond drop back toward the 6.x average of around 336, or stay elevated near the 7.x level of around 450, is something anyone can measure using the same tag-to-tag diff method. Once that number settles, it will finally be possible to debate whether the party Torvalds jokingly named really was the culprit — using something other than the commit count itself.