Linux 7.2 ships. The AI noise finally cleared the kernel's basement.

Linux 7.2 stable drops today. Linus’s rc7 email last week described it as “another exhausting AI-driven week” — not because of AI features in the kernel, but because LLM coding agents have apparently discovered the kernel mailing list and won’t stop generating patches and bug reports for drivers that last ran on hardware that belongs in a museum. The kernel is responding the only rational way: eviction.

What’s actually in 7.2 worth knowing about

Cache Aware Scheduling. The scheduler now understands last-level cache topology and tries to keep threads on the same LLC domain when it makes sense. If you’re running workloads that aren’t NUMA-aware but still thrash the cache boundary, this helps — without you doing anything. Worth benchmarking against 7.1 if you’re on a big multi-socket box.

MGLRU is better. Multi-Generational LRU continues to improve. Benchmarks during the merge window showed ~100% MongoDB throughput improvement on memory-pressured workloads. This is the page reclaim path doing real work. If you’ve been running vm.swappiness=0 as a blunt instrument, read up on MGLRU before you assume you still need to.

AMD Zen 6. Mainline support is in good shape. If you’re building boxes with Zen 6 silicon and currently running out-of-tree patches, 7.2 is the release where you can probably drop most of them.

x86 SRSO hardening. Speculative Return Stack Overflow mitigations got another round of improvements. You’re not going to notice it in benchmarks on most workloads, but if you’re running untrusted code on bare metal — which you shouldn’t be, but here we are — this matters more than you think.

Apple M3 boot. Upstream boot support landed. FreeBSD has been ahead on Apple Silicon in some respects, but it’s getting there.

The AI noise thing

This is the part that deserves more attention than the cache scheduling, honestly.

During the 7.2 development cycle, Linus and several maintainers made the same observation: LLMs are now scanning the kernel source tree continuously and generating “contributions” — patches, bug reports, security findings — for old code. The code being targeted is ancient: ISDN subsystem, Moxa serial drivers from 1999, PCMCIA network adapters, IPWireless. Hardware that you cannot buy, that no one has run in a production environment since the Bush administration.

The kernel’s response was to just delete it. Linux 7.1 merged a pull that ripped out 138,000 lines — sorry, wrong link, that was about Rust — the ISDN/old-networking removal was its own thing. 7.2 continues the pattern. The Moxa driver took 2,200 lines with it. More will follow.

The reasoning, as stated plainly by maintainers: if we keep the code, the AI noise keeps coming. Maintainers have to triage it. The code doesn’t run on real hardware. The correct move is deletion.

I have complicated feelings about this.

On one hand: yeah, fair. Dead code that nobody maintains is a liability. It collects security findings. It bitrotted decades ago. The maintainers who wrote it are long gone. When something breaks in there, nobody who understands it is around to fix it. Deleting it is correct software engineering.

On the other hand: we are now in a world where the kernel’s curation decisions are being driven by the behavior of LLMs. The code isn’t being removed because a human determined it was dead. It’s being removed because robots won’t leave it alone. That’s a new and slightly strange kind of selection pressure on what survives in a codebase. You can agree with the outcome and still find the mechanism worth a raised eyebrow.

The more this happens, the more the “what stays in the kernel” question gets shaped by what LLMs notice versus what they don’t. Ancient ISDN code gets noticed because it’s old C with known vulnerability patterns. What doesn’t get noticed? The stuff that’s too weird for the training data. Which is not necessarily the less important stuff.

This is not the first time the AI slop question has landed on the kernel mailing list, and it won’t be the last. The kernel community is handling it pragmatically — they’re not complaining about AI in principle, they’re just deleting the code that attracts the noise. That’s the correct tactical response. It doesn’t resolve the strategic question.

The actual numbers

rc7 had 400+ fixes from 230+ contributors, which Torvalds himself flagged as larger than normal. He attributed it partly to AI tooling and called it the “new normal.” He shipped it anyway because nothing in the batch looked genuinely scary, and there’s no value in an rc8 to fix AI-noise-induced patch volume.

The 7.3 merge window opens Monday. Which means the next round of noise starts Monday.

What you should actually do

Update to 7.2 when your distro ships it. Watch the MGLRU numbers on anything memory-pressured — if you have headroom in RAM and your workload was swapping under 7.1, benchmark before you tune. The cache scheduling gains are transparent but real on multi-LLC systems; check with perf stat before and after and see what the LLC-load-misses numbers say.

If you’re pinning processes to cores already, the cache-aware scheduler doesn’t replace that — it helps the unaffiliated workloads that you haven’t bothered to pin. Your pinned processes stay pinned.

And if you were writing a bot to file kernel bug reports: the maintainers see you. They’ve decided the correct response is to delete the code instead of engaging with the reports. Keep that in mind before you point your LLM at anything else upstream.