Linus Torvalds released Linux 7.3-rc3 on September 13, describing it as “another fairly large rc release.” The bulk is filesystem and network filesystem work: XFS and the SMB client, with netfs, AFS, EROFS, and Btrfs also represented.

Stable 7.3 remains on track for the second half of October, with roughly four more candidates expected.

The EROFS change is the one to read

Buried in a large rc is a change that matters more than its size suggests: EROFS has disabled LZ4 rolling decompression because of a data corruption possibility, and the fix is expected to take time.

EROFS is the Enhanced Read-Only File System, used extensively for Android system images and increasingly for container image layers and immutable distributions, where a read-only compressed filesystem is exactly the right shape. Rolling decompression is an optimisation that lets it decompress across block boundaries without buffering whole units.

Disabling an optimisation rather than fixing it in place is the correct call when the failure mode is silent corruption, and it is worth registering what that trades: EROFS reads using LZ4 will be slower until the proper fix lands. If you run something built on EROFS at scale, that is a performance change arriving in 7.3 that has nothing to do with your workload.

This is also a reasonable argument for the release-candidate cycle existing. The problem was found and contained before stable rather than after.

The AI patch volume has not eased

Greg Kroah-Hartman warned when rc2 landed that 7.3 was likely to be another rough cycle because of AI-generated bug reports and patches. Three weeks on, the surge is still being reported as a feature of the cycle rather than a spike that passed.

The kernel’s position remains what it has been: the human sending the patch must understand it and stand behind it. That is close to what Debian adopted by vote last month, and notably more permissive than the rule that just cost Void Linux a maintainer and 113 packages.

The kernel has one structural advantage in handling this that smaller projects lack: a maintainer hierarchy where rejection is routine and carries no social cost. A subsystem maintainer declining a patch is a Tuesday. In a small project, the same rejection is a relationship.

What a large rc3 signals

A release candidate cycle normally shrinks: rc1 is enormous because the merge window just closed, and each subsequent one is smaller as only fixes land.

An rc3 that is still large usually means one of two things. Either a subsystem merged late and is now settling, or something is genuinely unstable and generating more fixes than expected. Torvalds attributed this one to an outsized filesystem contribution rather than to trouble, which is the benign reading, and the shape of the next two candidates will confirm or contradict it.

Testing

Not on anything you care about. Filesystem changes are exactly the category where a regression costs you data rather than an afternoon, and rc3 contains a great deal of filesystem change.

If you do test, the useful contribution is unusual storage: uncommon controllers, network filesystems under load, EROFS-backed images, and Btrfs configurations more complicated than a single disk. That is where the remaining problems in this cycle are most likely to be, and it is what maintainers cannot easily test themselves.

uname -r
cat /proc/cmdline

The current stable kernels are 7.2.5 and 6.18.51, which is what should be running on anything in use.

Sources: Phoronix and the kernel archives.