Linus Torvalds released Linux 7.3-rc4 on September 20, opening with a line that has become the running joke of this cycle: “We all know the drill by now: ‘it’s big, yadda yadda’.”

He is not worried about it. That distinction matters, and it is the whole story of this release candidate.

Filesystems are the pattern, not a single filesystem

The detail Torvalds himself flagged as interesting is that filesystems keep making up an outsized share of a large rc, and that it is not the same filesystem twice.

rc3 was dominated by XFS and the SMB client. This time it is SMB and NTFS. Torvalds put it plainly:

“What I do find a bit interesting is that filesystems continue to be quite a noticeable part of the whole ‘it’s bigger than usual’. This time around it’s smb and ntfs, so it’s not like it’s one particular filesystem, it’s just been that filesystems in general seem to have been getting more attention recently.”

That is a meaningful distinction. One filesystem generating fix after fix across several candidates suggests something merged before it was ready. A different filesystem each time suggests the storage layer as a whole is simply getting more eyes this cycle, which is the benign explanation.

The NTFS presence is worth connecting to the complete NTFS driver replacement that landed in 7.1. A driver rewritten from scratch after four years of out-of-tree development is going to generate fixes for several cycles. That is the expected cost of the swap, not a sign it was a mistake.

The patch split

Torvalds broke the release down roughly into thirds:

• Drivers, still the largest single category but, in his words, “not as dominatingly as they sometimes are”
• Filesystems and networking
• Misc, meaning architecture fixes and tooling

The largest single patch in the whole release is administrative rather than interesting. A file was moved from lib/ to mm/ during the merge window, the original copy was never deleted, and rc4 contains the belated removal.

The LLM pattern has settled into something specific

Torvalds was more precise here than the general “AI is generating patch volume” framing this cycle has attracted:

“There’s a lot of error path cleanup stuff, which various LLM’s seem to be pretty good at catching, but that typically isn’t going to be all that noticeable in normal use. But hey, if any of the issues hit you, you are going to care.”

That is a fair characterisation of what static analysis, whether from a language model or a traditional tool, is actually good at. Error paths are the least-tested code in any kernel. The success path runs constantly. The branch that handles a failed allocation on the third of five initialisation steps may never run on your machine, which is exactly why leaks and missing unlocks accumulate there and exactly why a tool that reads every branch mechanically finds them.

The honest read is that this is unglamorous, genuinely useful work, and almost invisible until the day the allocation does fail.

It also sits in noticeable contrast to the governance fights happening elsewhere in the ecosystem. Greg Kroah-Hartman warned at rc2 that the cycle would be rough because of AI-generated reports and patches. Four candidates in, the kernel’s answer has held: the human sending the patch has to understand it. That is broadly what Debian adopted by vote, and considerably more permissive than the origination rule that cost Void Linux a maintainer and 113 packages.

What else went in

Four items merged this week are covered separately:

• Important x86 and x86_64 fixes
• Two notable Btrfs bugs
• New game controller support in the XPad driver
• A silent user-space data loss bug that has been present since 2023

That last one is the most consequential thing in the neighbourhood of this release, and it is worth reading on its own.

Timing

Linux 7.3 is expected in October. rc4 of a typical seven-candidate cycle means roughly three more weeks.

# check what you are running
uname -r

# the 7.3 cycle so far
git log --oneline v7.3-rc3..v7.3-rc4 | wc -l

Should you test it

The same advice as rc3 applies, and for the same reason. Not on anything holding data you would miss. An rc that is disproportionately filesystem changes is an rc where a regression costs you files rather than an afternoon.

If you do test, the valuable contribution is the configuration maintainers cannot easily reproduce: SMB shares under real load, NTFS volumes written by Windows and then read by Linux, Btrfs across multiple devices, and storage controllers that are not the three everyone owns. Our kernel panic guide covers capturing the evidence if something does go wrong, and hardware versus software RAID covers why a multi-device Btrfs setup deserves particular care during an rc cycle.