Linux 7.0 RC6 Is Busier Than It Should Be, and Torvalds Isn't Happy About It

Linux 7.0-rc6 is out. Linus Torvalds is not happy about it. Not because anything is catastrophically broken — but because the release candidate cadence this entire cycle has been weird, and RC6 just killed the one hopeful sign RC5 gave us. He's also now floating the idea that AI coding tools are changing the shape of how bugs get found. The EXT4 fixes in this drop are the kind that should make anyone running Linux in production stop and pay attention.

Let's back up. If you don't live and breathe the kernel release cycle, here's the rhythm: Linus merges features for two weeks after a stable release, then the RCs start. One per week. Each one is supposed to be smaller and quieter than the last as the code settles. By RC6, you're supposed to be in the home stretch. The tree should be boring. Boring is the goal. Boring means "we're basically done."

RC6 is not boring.

"It turns out that rc5 finally starting to calm things down this release cycle was a mirage — with rc6 we're back to many more fixes than are normal for this time in the release. It's not like anything in here looks particularly alarming, but the fact that the rc's this release has been pretty consistently bigger than normal doesn't exactly give me the warm and fuzzies."

That's Linus on the Linux Kernel Mailing List, March 29, 2026. "Warm and fuzzies" is his tell. He's used that phrase before in RC cycles that worried him. It's what he reaches for when he can't point at a specific smoking gun but the pattern is off and his gut knows it.

The full quote goes further. This is the part that caught my attention:

"A lot of pretty trivial — but real — fixes. I wonder if some of it is just AI tools being better — and we've hit some 'bump' related to that. Anyway, exactly because it's just 'more than usual' rather than feeling worse than usual, I don't currently feel this merits extending the release, and I still hope that next weekend will be the last rc. But it's just a bit unnerving how this release doesn't want to calm down, so no promises."

No promises. From Linus. The man has been doing this for 35 years. He has a release rhythm embedded in his bones at this point. When he says "no promises," he means RC8 is live on the table.

The Whole Cycle Has Been Running Hot — This Isn't New

This isn't a one-week blip. The 7.0 cycle has been weird since the start.

RC2 came in massive — one of the largest second release candidates in recent kernel history. Torvalds initially wrote it off as "random timing noise." Then RC3 arrived even bigger, which killed that theory. His revised explanation: the 6.19 cycle got dragged to a rare RC8, which created a backlog of pent-up work that flooded into 7.0 once the merge window opened. One cycle's debt bleeding into the next.

RC4 brought a wave of networking subsystem pulls on top of that, with what Torvalds called a "hey, new major number" psychological effect — developers sending in more patches than usual out of excitement about the 6.x to 7.0 jump.

RC5 finally looked like it was settling. We were cautiously optimistic. Torvalds himself said things were calming down.

That was the mirage.

And now Torvalds is adding a new theory on top of the backlog explanation: AI coding tools are getting good enough to surface bugs that used to slip through unnoticed. If that's true, you'd expect the kernel's fix commit count to creep upward across cycles even if the underlying code quality hasn't changed. The bugs were always there. The tooling is just finding them. That's arguably a good thing — except it creates a weird artifact at the RC stage where the tree refuses to go quiet the way historical patterns predict it should.

What's Actually in RC6 — And Why EXT4 Should Make You Stop Scrolling

Here's Linus's own breakdown:

"Filesystems kind of stand out in this release with a noticeable portion of the diffstat being various filesystem or vfs fixes where ext4 and xfs lead the pack. There are obviously the usual driver fixes for gpu, rdma, networking, sound and hwmon but drivers make up only about a third of the changes in total."

Drivers at only one-third of the diff. Let that land. In a normal RC, drivers dominate — they're the noisiest corner of the tree and constantly accumulate vendor-specific quirk fixes. When drivers drop to a third and filesystems climb to the top of the diffstat, something different is happening.

The EXT4 pull is the centerpiece. Ted Ts'o — who has been maintaining EXT4 for going on twenty years — sent Linus this on the morning of March 29:

"A lot of ext4 bug fixes including:Fix a number of Syzkaller issues.Fix memory leaks on error paths.Replace some BUG and WARN with EFSCORRUPTED reporting.Fix a potential crash when disabling discard via remount followed by an immediate unmount.Fix a corner case which could lead to allocating blocks for an indirect-mapped inode block numbers > 2**32.Fix a potential crash caused by the fast commit flush path potentially accessing the jinode structure before it is fully initialized.Fix fsync(2) in no-journal mode to make sure the dirtied inode is written to storage.Fix generic/475 failures caused by ENOSPC errors while creating a symlink when the system crashes resulting in a file system inconsistency when replaying the fast commit journal."

Read that list again. Slowly.

This is not cosmetic cleanup. This is: crash conditions, memory leaks on error paths, fsync(2) not actually writing the inode to storage in no-journal mode, integer overflow on inode block numbers, and fast commit journal corruption on ENOSPC. Each one of those is a category of bug that either corrupts data silently or takes your system down under specific conditions.

The fsync one is the one I'd lose sleep over. fsync is a contract. When it returns, your data is on stable storage — that's the whole point of calling it. Databases rely on this contract. Write-ahead logging systems rely on this contract. PostgreSQL calls fsync to guarantee crash recovery. If EXT4 in no-journal mode wasn't honoring that contract, any application trusting it was operating on a broken assumption.

To understand why these bugs are hard to catch, look at what EXT4 is managing at the C level. Here's the start of the inode allocation function in the upstream kernel tree at fs/ext4/ialloc.c:

/* Source: torvalds/linux — fs/ext4/ialloc.c
 * https://github.com/torvalds/linux/blob/master/fs/ext4/ialloc.c
 */
 
struct inode *__ext4_new_inode(struct mnt_idmap *idmap,
                                handle_t *handle, struct inode *dir,
                                umode_t mode, const struct qstr *qstr,
                                __u32 goal, uid_t *owner, __u32 i_flags,
                                int handle_type, unsigned int line_no,
                                int nblocks)
{
    struct super_block *sb;
    struct buffer_head *inode_bitmap_bh = NULL;
    struct buffer_head *group_desc_bh;
    ext4_group_t ngroups, group = 0;
    unsigned long ino = 0;
    struct inode *inode;
    struct ext4_group_desc *gdp = NULL;
    struct ext4_inode_info *ei;
    struct ext4_sb_info *sbi;
    int ret2, err;
    struct inode *ret;
    ext4_group_t i;
    ext4_group_t flex_group;
    struct ext4_group_info *grp = NULL;
    bool encrypt = false;

Look at handle_t *handle. That's the journaling transaction handle. Every single inode allocation is wrapped in a journal transaction to guarantee atomicity — either the entire operation commits, or it's rolled back cleanly on crash. The ext4_group_t types track which block group we're allocating from. struct ext4_group_info *grp holds the in-memory state of that block group including per-group spinlocks.

The bug Ts'o fixed involving lazy inode table initialization lives in the interaction between this path and EXT4's background init feature. EXT4 doesn't initialize the full inode table on mount — it does it lazily in the background to avoid blocking at mount time on large filesystems. When "avoid recently deleted inodes" logic and lazy init are both active, there's a window where the allocator evaluates an uninitialized inode table entry as if it were a real inode. You get garbage, or you get e2fsck complaining your filesystem is inconsistent even though nothing is actually wrong. That's exactly the kind of timing-sensitive bug that Syzkaller's kernel fuzzer is built to find through randomized concurrent workloads.

This is also exactly why Ts'o's involvement is reassuring even in a noisy RC. He doesn't send Linus junk. His pulls go through extensive review. When he sends a list this long at RC6, every item on it is a real bug that someone found under real conditions.

XFS Is Also In This, For the Same Reasons

XFS has been generating patches throughout the entire 7.0 cycle — it was showing up heavy as far back as RC2. XFS is the default filesystem on Red Hat Enterprise Linux and its derivatives, which means it's running a material fraction of enterprise servers worldwide. Bugs in XFS hit harder than bugs in driver quirk code.

The RC6 XFS patches continue fixing issues in the journaling and extent management subsystems. XFS uses log-based journaling (different architecture from EXT4's block journal), and its extent tree — the B+ tree structure tracking which disk blocks belong to which file — gets complex fast under concurrent write workloads. A race condition in extent tree operations is exactly the kind of thing that shows up as data corruption under sustained I/O load, and only when two specific code paths collide at the exact wrong moment. Production servers are where you find these, usually after it's already too late.

Both major Linux filesystems generating this volume of fixes at RC6, rather than RC2 or RC3, is the specific data point worth watching.

What Actually Happens Next

RC7 drops around April 5. That's the signal.

If RC7 is small and quiet — Linus says "nothing interesting, we're done" — then Linux 7.0 stable ships April 12. One more boring week closes it out.

If RC7 is as large as RC6, he extends. RC8 lands April 12, stable ships April 19. Both dates are within the normal window. Neither is a catastrophe. But the RC8 scenario means the pattern — this cycle refusing to settle — held all the way through seven release candidates.

The AI tooling angle is genuinely interesting to think about longer term. If better static analysis and AI-assisted code review are raising the floor on bugs-found-per-week across the kernel community, the historical signal of "RC6 quiet = almost done" starts degrading as a predictor. The kernel development community is going to have to think about what the new normal looks like when the tooling keeps getting better.

Linus noticed. He doesn't have an answer. That's the most honest and interesting thing he's said in an RC announcement in recent memory.

Keep an eye on RC7. And if you're running EXT4 in no-journal mode anywhere in production, it might be worth confirming your fsync behavior is what you assumed it was before 7.0 ships.