Linux 7.2-rc5 shipped on Sunday, July twenty sixth, and more than a third of it is networking, almost all of that on the driver side rather than in the core stack. Linus Torvalds described it as quite a massive rc5 and, in the same breath, said nothing in it struck him as particularly strange or scary. Both halves of that sentence matter if you are deciding what to test. A late cycle release candidate this large is unusual, the explanation he offered is mundane, and the shape of the diff tells you exactly which machines are worth putting under load before the stable release lands on August sixteenth.
The short answer
Linux 7.2-rc5 arrived on July twenty sixth, unusually large for a late cycle release candidate. Over thirty five percent of the changes are in networking, almost entirely driver side, which Torvalds put down to a backlog clearing after a week of conferences. USB changes outnumbered GPU changes, an unusual inversion this late. His verdict was that it is a bit too big for his liking but nothing strikes him as particularly strange or scary. Stable is targeted for August sixteenth.
Release candidates are supposed to get smaller as a cycle winds down. That is the entire point of the shape: the merge window takes the features, and the seven weeks after it are meant to be a decreasing series of fixes until the curve flattens and Torvalds tags a stable kernel. So when rc5 arrives visibly bigger than rc5 usually is, the interesting question is not whether that is bad. It is why.
What Torvalds actually said
The announcement gave both the complaint and the reassurance. He called it quite a massive rc5, and then: it is a bit too big for my liking, but nothing strikes me as particularly strange or scary.
Reading those together is the whole skill. Size and risk are separate axes, and conflating them is how people end up either ignoring a genuinely dangerous small patch or panicking over a harmless large one. A five thousand line diff that fixes quirks across two hundred specific network cards carries a fundamentally different risk profile from a two hundred line change in the memory management subsystem. The first affects only people with that hardware and fails visibly. The second can affect everyone and fail subtly.
His explanation for the volume was equally unglamorous. Maintainers had been at conferences the week before, so pull requests that would ordinarily have arrived spread across two weeks landed compressed into one. That is a calendar artefact, not a signal about code quality. He has separately described larger kernels as the new normal, which is worth noting as background: the baseline has been creeping up regardless of any particular week.
Where the changes actually are
Networking took over thirty five percent of the total, and the important qualifier is that it was mostly drivers rather than core protocol work. Changes to the network stack itself, the parts that decide how packets are queued, congested and routed, are the ones that can affect every machine. Changes to a particular vendor's NIC driver affect exactly the people running that NIC.
The second detail is a genuine oddity: USB changes outnumbered GPU changes this cycle. GPU drivers are normally the loudest single contributor to kernel churn by sheer volume, so an inversion this late in a cycle is unusual enough to be worth a mention.
Beyond those two, the release spread across sound, TTY, block, firewire, filesystems including SMB and btrfs, the Rust bindings, architecture specific fixes, tooling in selftests and perf, and documentation. There is a nice bit of kernel archaeology in there too: a firewire IPv4 networking bug that had apparently been sitting untouched since around 2009 finally got fixed. Hardware specific work included Intel Panther Lake Xe3 graphics performance and PCIe 5.0 storage tuning on AMD EPYC Turin.
Testing this one, if you are going to
Whether to bother depends entirely on what you run. The value of testing a release candidate is that regressions get found on your hardware before they reach a stable kernel that ends up in a distribution you actually deploy. That value is real, but it only exists if the test machine resembles the production machine in the ways that matter.
For this rc in particular, that means network cards. Over a third of the changes live there, so if you operate anything with a NIC that is not the most common consumer part in the world, you are in the population that can find something nobody else will. Bonding, VLANs, offload settings and anything that pushes the driver into its less travelled paths are where driver regressions surface, and none of them appear under light load.
USB deserves a look too, given that it outweighed GPU work this cycle. If you have serial adapters, capture devices or anything USB attached that a service depends on, exercise it rather than assuming it.
The mechanics are unchanged and unremarkable. Pull the mainline tree, check out the v7.2-rc5 tag, start from your running configuration with a copy of the config in /boot followed by make olddefconfig so the new symbols get sensible defaults, build, install the modules and the kernel, and boot it. Keep the previous kernel in the bootloader, which any sane distribution does by default, so that a bad boot costs you one reboot rather than a recovery session.
The one rule that does not bend is where you do this. Release candidates go on staging boxes and spare hardware, not on anything carrying traffic that matters. That is not caution for its own sake, it is the arrangement that makes rc testing worth doing at all: the whole system depends on problems being discovered somewhere that a crash is merely annoying.
What to watch next
The schedule points at August sixteenth for 7.2 stable, which leaves rc6 and rc7 at roughly weekly intervals. The signal to watch is whether rc6 comes in noticeably smaller. If the conference backlog explanation is the right one, it should, because a one off compression of pull requests does not repeat. If rc6 arrives large as well, the backlog story looks less complete and an extra release candidate becomes more plausible, since Torvalds does extend a cycle when something late looks unsettled.
For most people the practical answer is to wait for the stable tag and let the distribution do the integration work. For anyone running unusual network hardware, the next three weeks are the window where finding a problem is still cheap.
Sources and further reading
- Phoronix: Linux 7.2-rc5 released, once more we have quite a massive rc5
- Linux Compatible: Linux kernel 7.2 rc5 released, massive networking patch push targets stable on August 16
- Neowin: Linux 7.2-rc5 lands with patches for HP EliteBook 830 G8 and Alienware x16 R2
- The Linux Kernel Archives
Frequently asked questions
Is an oversized rc5 a reason to worry about 7.2?
Not on its own. Size and risk are different measurements, and Torvalds addressed both explicitly: too big for his liking, but nothing that struck him as strange or scary. The distinction is real, because a large diff made of driver fixes for specific hardware is far less dangerous than a small diff touching a scheduler or a memory management path. This one is dominated by drivers. What an oversized rc5 does mean is that less of the cycle remains to shake out whatever slipped in, which is an argument for testing sooner rather than for skipping the release.
Why did so much networking code land this late?
Torvalds attributed it to backlog rather than to anything structural. Maintainers had been at conferences the previous week, so the pull requests that would normally have trickled in across two weeks arrived compressed into one. That is a scheduling artefact of how kernel development actually works, not a sign that networking is in trouble. He has also described larger releases generally as the new normal, so the baseline itself has been drifting upward for a while.
Which subsystems should I actually test?
Start with networking drivers, since that is where over thirty five percent of the changes are, and specifically the NICs you run in production rather than the ones you own. After that, USB is worth a pass because USB changes outnumbered GPU changes this cycle, which is an unusual inversion late in a release. Sound, TTY, block, firewire, SMB, btrfs, Rust bindings, perf and the selftests all saw work too, so if you depend on any of those, this is the rc to exercise.
When does 7.2 stable actually arrive?
August sixteenth, 2026, on the current schedule, which is just under three weeks from rc5. That assumes the cycle runs to the usual length with rc6 and rc7 following at weekly intervals. Torvalds does extend a cycle by an extra release candidate when something late looks unresolved, so treat the date as the plan rather than a guarantee, and watch whether rc6 comes in noticeably smaller.
Should I run an rc on anything that matters?
Not on production, no, and that has not changed. Release candidates exist so that problems surface on machines where a reboot is cheap. The useful pattern is a staging box or a spare machine whose hardware genuinely matches production, because a driver regression only shows up on the silicon it affects. Testing 7.2-rc5 on a laptop tells you very little about the NIC in your rack.