The 7.2 kernel has been released [LWN.net]

The 7.2 kernel has been released. Linus said:

Well, this last week of the release was - once again - bigger than I would have wished for, but hey, with the whole "new normal" thing, if I delayed releases for that reason we'd probably never have a release at all.

Significant features in this release include common attributes support in the bpf() system call, cache-aware load balancing for the CPU scheduler, large-folio support in the Btrfs filesystem, further swap subsystem improvements, improvements to the Landlock security module, support for block devices with inline encryption hardware via the dm-inlinecrypt device-mapper target, and much more. See the LWN merge window summaries (part 1, part 2) and the KernelNewbies 7.2 page for more information.

to post comments

more time to bake

Posted Aug 17, 2026 2:51 UTC (Mon) by rolexhamster (guest, #158445) [Link] (6 responses)

this last week of the release was - once again - bigger than I would have wished for, but hey, with the whole "new normal" thing, if I delayed releases for that reason we'd probably never have a release at all.

That sounds like a cop-out. If the kernel needs more a little more time to bake, then so be it. The quality of recent .0 releases has anectodally dropped compared to say 6 to 12 months ago.

Maybe all the recent LLM based bug "finding" is correcting some surface-level symptoms, while at the same time destabilizing the codebase via subtly breaking tacit or under-documented assumptions and data flows.

more time to bake

Posted Aug 17, 2026 13:59 UTC (Mon) by csamuel (✭ supporter ✭, #2624) [Link] (5 responses)

I think Linus's point is that the incoming rate of fixes is so high that if he waits for it to drop we'll be waiting a long time for a release. A fair few of these turn out to be security related (there were another 800+ kernel CVEs published on Saturday).

I do take your point about the unintended consequences of this high rate of change. I am not sure what the answer there is other than more people, code and resources to do much more thorough testing of these quickly to spot those issues.

more time to bake

Posted Aug 18, 2026 1:40 UTC (Tue) by rolexhamster (guest, #158445) [Link] (2 responses)

At the risk of stating a tautology, a new kernel release is just a time point at which more testing starts, while the development of a new kernel continues in parallel.

In my experience, a new kernel is mostly derisked by about the 10th update. In other words, kernel 7.2 is not really going to be "stable" until 7.2.10 or so.

Of course, one can use LTS kernels which have a lower rate of change, but the current seemingly ad-hoc process of backporting fixes introduces risks as well, as recently experienced. There should definitely be more judicious selection of what to fix and what to backport.

more time to bake

Posted Aug 18, 2026 6:51 UTC (Tue) by taladar (subscriber, #68407) [Link]

> There should definitely be more judicious selection of what to fix and what to backport.

This view ignores completely that judging the potential consequences of each fix is somewhere between "a lot more resource intensive" and "impossible" when compared to just fixing the issue.

more time to bake

Posted Aug 18, 2026 16:37 UTC (Tue) by iabervon (subscriber, #722) [Link]

The issue is that we're finding that no kernel ever released has been adequately bug-free, and it doesn't make sense to hold up releasing 7.2.0 until people stop finding bugs that are still in the 7.1 series and had been in the kernel for years when 7.1.0 was released.

As far as getting a production-suitable kernel, it doesn't really matter whether the kernel before the first 7.2 one you can really rely on is 7.2.9 or 7.2-rc14, and I think your observation about the .0 kernels suggests that production-readiness improves more rapidly after Linus hands it off than before, which would mean that it would need to bake even longer if it was released later.

The real reason for not releasing a .0 right after the merge window is to avoid having .0 kernels with mutually incompatible behavior (as much as possible), since this lead to a situation where different users come to rely on different behavior and the kernel can't decide which to do. Once series that are leading to unsolvable problems have been reverted, it makes sense to nail down the feature set and move to the process where it really bakes.

more time to bake

Posted Aug 18, 2026 20:11 UTC (Tue) by corbet (editor, #1) [Link] (1 responses)

Waiting for all of the bugs to be fixed (or some semblance thereof) is what we did through the 2.6.0 release. That meant two or three years between kernel releases, and did not result in higher-quality kernels. There really does come a point where you have to put it out there, get more people using it, and fix the remaining issues in parallel with further development.

more time to bake

Posted Aug 18, 2026 21:34 UTC (Tue) by ebiederm (subscriber, #35028) [Link]

A lot of what went into 2.5.x was under baked compared to what goes into kernels following the current "time" based release process.

I know of several 2.5 era issues that are still unfixed, and I am slowly working on one of them.

Still I don't know if it would even be possible to introduce support for POSIX threads any other way.