What is Linux 7.4-rc1 and why is it unusually large?
Linus Torvalds tagged Linux 7.4-rc1 on 1 November 2026. The release candidate closes the merge window that opened with Linux 7.3 on 18 October. In his announcement, Torvalds wrote: "This is a *BIG* merge window." He put the size at almost 20,000 commits, against the more common 15,000.
Phoronix called it easily the largest merge window in the kernel's roughly 35-year history. A normal two-week window brings in roughly 15,000 commits, so 7.4 is a clear outlier. Phoronix also reported that the source tree is approaching 42 million lines.
Here is how the cycle works. After a stable release, maintainers send Torvalds pull requests for features and large rewrites. That merge window usually lasts about two weeks, and it can run longer. The tree then enters a stabilisation phase with weekly release candidates, usually up to rc7. The stable release follows about nine to ten weeks after the previous version.
That cadence makes rc1 a boundary. New features are supposed to stop arriving once the first candidate is cut. From rc1 onward, patches should fix problems rather than add them. The size of the window therefore sets the tone for the review weeks that follow.
Release candidates are not feature drops. They are checkpoints where Torvalds and subsystem maintainers judge whether the merged work is settling. A large rc1 therefore raises a simple question: did the extra work arrive with enough testing?
The diff is large for a second, less interesting reason. Torvalds wrote that "a full third of the patch is just AMD GPU register offsets and bit masks." He advised readers to "just ignore the noise." Strip out those headers and the release looks fairly normal.
It is still broad: Torvalds described roughly half the changes as drivers. Architecture updates, filesystems, perf and selftests, networking, Rust, BPF and memory management fill the rest. The merge summary lists work across VFS, XFS, Btrfs, ext4, NFS, io_uring, KVM and Rust. The shortlog alone is 24,000 lines and 1.2MB.
Two explanations account for the extra volume. The first is AI-triggered work arriving earlier than usual. The second is the expectation that 7.4 will become the next long-term support kernel. Torvalds called that "another independent reason why some releases tend larger than others." The kernel.org LTS list currently stops at 6.18, released on 30 November 2025. No announcement has designated 7.4 yet.
Torvalds also said two pull requests were still in his inbox. He did not delay rc1 to decide on them. They may or may not appear in rc2. The release candidate is therefore a snapshot of a very large window, not a claim that every pending change made it in.
Why does the size of a merge window matter?
The kernel separates new work from repair work on purpose. Merge windows accept features, and release candidates are meant for testing and quiet fixing. When repairs arrive late, they compete with stabilisation instead of flowing through normal development.
AI tools have changed the volume of both. They can inspect large codebases quickly and suggest fixes at a scale humans cannot match. New code merged in the window also gives them fresh material to review. That timing naturally pushes some fixes into the rc weeks.
A commit that arrives in the merge window gets more review time before release. A fix that arrives in rc6 has days, not weeks. That is why Torvalds treats timing as a quality signal, not just a scheduling detail.
Torvalds sees the 7.4 pattern as an improvement. He wrote he is "much happier with the flood of AI triggered work going into the merge window" than with it appearing as extra fixes later. He added: "I think that's a much healthier model. But we'll see how the -rc's look."
The qualifier matters. A large merge window does not prove that AI fixes have become routine. It shows only that more of them arrived before rc1. Torvalds also noted that AI-suggested patches "often get rewritten", so human review is still doing substantial work.
Earlier cycles showed the opposite pattern. XenoSpectrum counted commits carrying the Assisted-by tag, which contributors used to declare AI help. In Linux 7.3, tagged commits were 8.2% of the merge window and 19.3% of the rc period. In 7.2, the shares were 5.3% and 13.4%. The rc periods carried 3,498 and 3,006 non-merge commits respectively. Those are the baselines for judging 7.4.
The 7.4 merge window changed the first part of that picture, at least among commits where use was declared. Tagged commits rose to 16.2% of the window. Whether the rc period becomes quieter is the test still to come. If it does, Torvalds's reading will have support. If it does not, the shift may be mostly about timing.
How much of Linux 7.4 was written with AI help?
The precise answer is unknown; the best available count comes from XenoSpectrum. Its editors tallied non-merge commits between the v7.3 and v7.4-rc1 tags in the official torvalds/linux repository. They found 18,591 non-merge commits. Of those, 3,008 carried an "Assisted-by:" line, or 16.2%.
The method behind the count was straightforward. XenoSpectrum searched commit messages for the trailer at the start of a line and ignored case. It then compared the 7.4 window with the two previous cycles.
Including merge commits, the window contained 19,780 commits. That is close to Torvalds's "almost 20k" description. Declared AI-assisted commits were about 2.4 times the 1,257 tagged commits in the 7.3 merge window. The 7.3 window had 15,267 non-merge commits in total. The 7.2 window had 13,412.
Raw growth is not the only measure, because the baseline was already rising. Non-merge commits rose by 3,324 between the two windows. Tagged commits accounted for 1,751 of that increase, or about 53%. The rest came from untagged work, which may include LTS-related changes and other factors.
The count has a large blind spot, and the kernel's own rules created it. The Assisted-by tag was voluntary, and it was removed during the 7.4 merge window. The removal commit said only about 10% of the 18,533 non-merge commits in 7.3 through rc7 carried the tag. Actual LLM use was "far more widespread", according to that commit.
At the Maintainers Summit, David Airlie estimated that "probably 90%" of contributors use LLMs. That was an estimate rather than a survey of contributors. It shows the gap between declared use and real use. The 16.2% figure is therefore a floor for disclosed assistance, not a census.
A second limitation is that the tag recorded help, not its amount. A one-line autocomplete and a fully generated patch looked identical in the trailer. The tag also said nothing about AI use in review, testing or documentation. It covered only commits where someone chose to declare help. That ambiguity was central to the decision to remove it.
Why did Linux drop its AI disclosure tag?
The tag arrived in January 2026. A commit adding Documentation/process/coding-assistants.rst asked contributors to declare LLM help. The rule followed a consensus at the 2025 Maintainers Summit. The document was written partly for AI tools themselves. The commit message says the README points assistants to the rules so they can parse and follow them.
In August, Christian Brauner simplified the format to "Assisted-by: LLM". Naming specific models, he wrote, gave "free advertising to proprietary software companies" while adding little useful information. The change kept the disclosure but removed the model name.
Maintainers initially wanted the signal, and a proposal to remove the tag was rejected in July. The argument was that reviewers could treat AI-assisted patches differently if they knew about them. Without a reliable tag, that option disappears.
By October, the evidence had changed. The Maintainers Summit met in Prague on 8 October, with about 30 invitees. Attendees reviewed the disclosure rate: roughly 10% of commits carried the tag, while LLM use was much broader. Some contributors did not know the rule. Others left it off on purpose. Few maintainers asked.
The removal commit described a "strong, though not unanimous, consensus" to drop the requirement. Greg Kroah-Hartman, who had argued for keeping the tag in July, supported removal. Linus Torvalds said arguments about how to deal with people using LLMs are misdirected. XenoSpectrum's account adds that he compared tool bans to banning a compiler or an editor. The patch was committed on 14 October and reached mainline during the merge window.
The replacement is a cover letter, not a changelog line. Maintainers still want to know how a patch was made. The summit view was that a cover letter can explain tool use in context. Documentation/process/generated-content.rst already asks for transparency about substantial tool-generated content. It also lets maintainers reject such contributions or lower their review priority.
Accountability did not move. The Developer Certificate of Origin still requires a human signature. Kernel documentation states that AI agents must not add Signed-off-by tags. Only a person can certify the DCO and take responsibility for the patch. A separate procedure added in August sets mandatory steps for AI bug hunting. A report must include a reproducer. The fix must build without new warnings and pass checkpatch. The commit message must explain the problem and carry a Fixes tag.
The rules now focus on responsibility rather than disclosure. That is a deliberate choice. It also puts weight on reviewers to notice problems in patches whose origin is unclear. The kernel has traded a weak signal for a clearer rule about who answers for the code.
What else is in Linux 7.4?
AI policy dominated the conversation, but 7.4 also carries ordinary hardware and performance work. Phoronix highlighted performance improvements, preparations for AMD Ryzen Zen 6 processors, and AMDGPU HDMI 2.1 support enabled by default.
The Register, citing Phoronix, reported improved support for AMD, Apple and Google processors. The release also includes virtual-machine security tweaks, support for a Raspberry Pi 10-inch monitor, and more work on Qualcomm's Snapdragon X2 laptops.
Storage and filesystem changes are part of the package. Phoronix reported FAT32 optimisations that reached 265 times faster in one benchmark. That figure is a best-case result from a specific workload, not a general speed-up. Btrfs received zstd decompression improvements, and Ceph gained a global mount option for lazy I/O. Scheduler work covered load balancing, NUMA balancing and energy-aware placement.
Tooling received attention too. Phoronix reported that perf's Python scripts became more robust and faster. AMD's PerfOpt feature landed for integrated GPUs. These are not headline features for most users. They matter to developers who profile and tune systems.
The release candidate also includes updates to ARM and RISC-V platform support, EFI, PCI and power management. These are the routine changes that keep new laptops and servers booting. They rarely receive attention outside kernel circles, but they decide whether a machine works after an upgrade.
The features will not reach most users immediately. Distributions must pick up the kernel, test it on their hardware and ship it in a later release. Desktop and laptop users may wait months. Industrial and embedded users often stay on older LTS kernels for years. For them, the AI debate is less urgent than the stability of the branch they already run.
Linux 7.4-rc1 is also not a stable kernel. Kernel.org describes prepatch releases as aimed at developers and enthusiasts. They must be compiled from source and tested. Anyone installing it on a work machine is joining the test, not receiving a finished product.
What are the risks, and what happens next?
The optimistic reading is that AI helps find and fix bugs earlier. The pessimistic reading is that AI produces plausible but wrong reports, and humans pay the sorting cost. Both can be true at once.
At the summit, Kroah-Hartman said AI tools find many vulnerabilities but about half are false reports, according to XenoSpectrum's account. He also warned that the community should expect a "firehose" of fixes for the next 18 months. That forecast describes workload, not code quality. It is a prediction about how many patches maintainers expect to process.
Review capacity is the constraint: a wrong patch that is well formatted still consumes maintainer time. A correct patch with no explanation can consume more. The cover-letter guidance tries to address the second problem. It does not solve the first.
The next data point will be the rc period. Torvalds will publish release candidates weekly through November and December. XenoSpectrum's comparison points are 3,498 non-merge commits in the 7.3 rc period and 3,006 in 7.2. A lower 7.4 figure would be evidence that stabilisation is lighter. It would not prove that AI fixes declined.
The LTS decision is the other milestone. Kernel.org lists 6.18, released on 30 November 2025, as the newest long-term kernel. No official announcement has designated 7.4. If it is chosen, its stability will matter to distributions and industrial users. The Civil Infrastructure Platform, which maintains super-long-term kernels, counts Renesas, Toshiba and Hitachi among its members.
The debate is spreading beyond the kernel. On 2 November, Phoronix reported that Mesa's RADV Vulkan driver adopted an LLM policy. The site also reported on 30 October that PostgreSQL 19 is running behind schedule due to AI and LLM burden. Open-source projects are making similar decisions project by project.
The kernel's experience is a test case for other large projects. If review can absorb a 20,000-commit window without a heavier rc period, the model may spread. If it cannot, projects may tighten their submission rules instead.
Different readers have different stakes. For distribution maintainers, the question is whether a bigger merge window produces a rougher rc cycle. For enterprise users, it is whether 7.4 becomes the branch their vendor supports for years. For developers, it is whether their patches get reviewed at all.
If the usual rc7 schedule holds, Linux 7.4 would arrive in late December. Until then, the community is running a public experiment. The question is not whether AI can write kernel patches. It clearly can. The question is whether review can absorb them without turning stabilisation into a permanent backlog.