3 Minutes
Linux kernel development rarely throws curveballs this early, but Linux 7.0 just did. The second release candidate landed noticeably heavier than a typical RC2—and Linus Torvalds didn’t hide his annoyance, saying he wasn’t “super-happy” with how big it turned out.
Torvalds chalked it up to “random timing noise,” the kind of scheduling oddity that sometimes makes one week look chaotic and the next look calm. Still, the volume of non-merge commits hints at something messier than a simple blip: the Linux 7.0 development cycle may be starting off more volatile than usual, with a lot of real work landing all at once rather than trickling in.
What makes this RC2 especially interesting isn’t just the size—it’s what’s inside. Early kernel candidates often skew driver-heavy. Not this time. Drivers reportedly make up only about a quarter of the changes, while the bulk of the patchset digs into internal plumbing: core kernel work, networking tweaks, and filesystem updates. That’s the kind of change mix that can improve fundamentals, but it also carries a bigger blast radius when something goes sideways.
Filesystems, in particular, took a big slice of attention this week. Work touching the SMB client, XFS, and EROFS accounted for roughly a quarter of the update. The theme is reliability, the unglamorous stuff that keeps systems from quietly corrupting data or falling over under odd edge cases. XFS alone picked up 19 patches, spanning everything from inode counter statistics to potential pointer access races—exactly the sort of subtle bug class that can stay hidden until it suddenly doesn’t.
Under the hood, security and memory management also got a solid round of maintenance. Fixes landed for KASAN (KernelAddressSANitizer) issues involving hardware tags in the memory manager, alongside speculative-safety work tied to x86 FRED (Flexible Return and Event Delivery). These aren’t headline features, but they matter: the kernel’s defenses against side-channel style attacks and nasty memory faults tend to be built from small, careful changes like these.
Then there’s BPF. The update includes a sizeable batch of Berkeley Packet Filter changes and selftests, continuing the steady refinement of how Linux runs and validates sandboxed programs inside the kernel. This week’s work includes fixes aimed at out-of-bounds writes and race conditions—especially relevant for PREEMPT_RT configurations, where timing and concurrency bugs are more likely to show their teeth.
So why did everything pile up now? Torvalds suggested the Linux 6.19 cycle may be part of the explanation. That release was extended by a week, and the after-effect can look like a traffic jam: patches wait, pressure builds, and then the next merge window gets flooded. If that’s all this is, RC3 should quiet down and restore the usual rhythm.
But if RC3 comes in oversized again, it’s a different story. It would suggest Linux 7.0 isn’t just experiencing a one-week hiccup—it may be heading for a longer stabilization phase, with extra testing time before the stable kernel arrives. Either way, the next candidate will tell developers and distro maintainers whether this was noise… or the sound of a busy cycle ramping up fast.
Source: neowin
Comments
DaNix
Seen this before after a delayed merge window, ive had a tree explode after one of those traffic jams. reliability work snooze but essential. fingers crossed
mechbyte
Is Linus just being dramatic or is RC2 really that messy? feels like timing noise but those fs fixes (XFS, SMB) could bite later... hmmm
Leave a Comment