What's waiting for Linux 7.4
What's waiting for Linux 7.4
Linus tagged Linux 7.3 on Sunday 18 October, which opens the merge window for 7.4. For the next two weeks maintainers send their pull requests and Linus merges them, and at the end of it 7.4-rc1 comes out. Very little of what lands is new by then. Nearly all of it has been sitting in linux-next, the daily integration tree, for days or weeks.
Linux-next tells you what commits are queued, but not why. The why is in the mailing-list threads where each patch was posted, reviewed and revised. ratatoskr.run archives those lists, and its merge-window page joins the two: every linux-next commit that isn't in Linus's tree yet, linked back to the post it came from and grouped by MAINTAINERS subsystem. This post is a tour of that page as of the merge window opening.
The size of it
Comparing linux-next's next-20261016 against v7.3:
- 16,597 commits (merges excluded) from 2,470 authors
- 15,516 files changed, 1,022,088 insertions and 344,109 deletions
- about 30 pull requests for 7.4 had already reached Linus by Monday morning, from crypto, scheduler, locking, RCU, arm64, s390, Btrfs, Rust and more
Not every commit can be traced back to the list. The page relies on the Link: trailer that most trees add when applying a patch, and 11,248 of 16,622 commits have one (68%). Those resolve to 11,769 patches, posted as 829 series and 1,675 single patches.
Where the work is
By patch count, the biggest subsystems queued for 7.4:
| Area | Patches |
|---|---|
| BPF | 519 |
| Qualcomm (mailing list 260, clock drivers 157, SoC support 112) | 529 |
| Wireless (mac80211 130, iwlwifi 110, mt76 107, rtw89 103) | 450 |
| Intel graphics (Xe 249, Xe/i915 display 150) | 399 |
| KVM (x86 230, arm64 136) | 366 |
| Audio (ASoC 225, ALSA 119) | 344 |
| DAMON | 179 |
| NFS server, SunRPC and lockd | 141 |
| Kernel selftests | 137 |
DAMON, the memory-access monitoring subsystem, stands out for being almost a one-person effort: SeongJae Park has 168 patches in this window.
Series worth a look
BPF learns to reason about loops. Eduard Zingerman's scalar evolution series (52 patches) teaches the verifier to infer how a loop variable changes. For for (i = 0; i < 10; i++), the verifier can now treat i as the range 0 to 9 instead of walking every iteration. Next to it, Alexei Starovoitov's callx series adds indirect calls between BPF subprograms.
ext4 moves buffered I/O to iomap. Zhang Yi's series, now at v7 and 31 patches, converts ext4's regular-file buffered I/O path from buffer_heads to iomap. It's a long-running effort and a big step for one of the most widely deployed filesystems.
Confidential computing in KVM. Ackerley Tng's guest_memfd in-place conversion reached v13 and 44 patches. It lets guest memory change between private and shared without moving it to different pages. On arm64, Sascha Bischoff's GICv5 IRS support (48 patches) lets GICv5 guests use SPIs and LPIs. That makes guests with more than one vCPU possible, and a full Linux guest can now boot on Arm's FVP model. Sean Christopherson also has part 1 of cleaning up the KVM clock queued, which, as the series title puts it, is a mess.
Memory management. Lorenzo Stoakes's series (40 patches) retires VM_SPECIAL, a VMA flag mask that conflated several unrelated properties. The cover letter is worth reading just for how candid it is about the existing state of things.
Graphics. Maxime Ripard is converting every DRM driver from the overloaded reset hook to atomic_create_state, first for CRTCs (58 of 70 patches queued so far) and then for planes. Cristian Ciocaltea's HDMI 2.0 support for the DW HDMI QP controller brings 4K at 60 Hz to Rockchip RK3576 and RK3588 boards. 22 of its 74 patches are in linux-next so far.
Compiler-checked locking. Bart Van Assche's series (53 patches) turns on Clang's lock context analysis for nearly every SCSI driver. The compiler then checks lock and unlock pairs against their annotations and warns when a __guarded_by() field is touched without its lock. Error paths are where those bugs tend to hide.
Also queued:
- Christian Brauner's sparse coredumps over the coredump socket, so large processes with holey mappings stop streaming zeroes.
- Eric Biggers moving x86 and RISC-V accelerated AES modes into the crypto library.
- Johannes Berg's further RTNL reduction in wifi.
- Peter Ujfalusi's compressed audio support for SOF with IPC4.
- Gary Guo's safe self-references in Rust pin-init.
The trend: AI-assisted patches
The kernel has a trailer for disclosing AI tool use, Assisted-by:. Counting the commits that carry it:
| Release | Commits | With Assisted-by: |
Share | Authors using it |
|---|---|---|---|---|
| 7.1 | 15,849 | 294 | 1.9% | 82 |
| 7.2 | 16,418 | 1,110 | 6.8% | 238 |
| 7.3 | 18,765 | 1,932 | 10.3% | 438 |
| 7.4 (queued in linux-next) | 16,597 | 2,790 | 16.8% | 445 |
That's roughly a ninefold increase in share over four releases. It isn't a few heavy users either: 445 authors disclosed AI use in the 7.4 queue alone. The single most common form is a plain Assisted-by: LLM, followed by the various Claude, Gemini, Copilot, Cursor and Codex models.
Two series in this window show different ways of using the tools:
- Josef Bacik's 43 io_uring fixes came out of an LLM-driven audit. Some bugs were found by modelling the task_work, poll, io-wq and completion-queue code and running those models through a model checker, the rest by reading the code and writing a reproducer. Two of them are memory-safety bugs. Several are hangs any unprivileged user can trigger, and in three of those the stuck task can't be killed.
- Song Liu's unit test framework for klp-build (58 patches, with Puranjay Mohan and Joe Lawrence) was designed on the assumption that AI will write most future tests, with humans reviewing the framework itself. The cover letter notes it was written "100% by a human being".
AI is also turning up in review. Several cover letters in this window, ext4's among them, mention fixing issues raised by Sashiko, an automated reviewer, or rewording comments to head off its false positives.
These numbers have caveats. The trailer only counts disclosed use. Part of the growth is probably developers adopting the trailer itself, as well as using the tools more. And linux-next isn't 7.4: some of it will be held back or dropped during the merge window.
Reading the page yourself
The merge-window page updates with linux-next and with Linus's tree, so patches drop off as their pull requests are merged. A few things to keep in mind when reading it:
- Only commits with a
Link:trailer can be shown. About a third of linux-next has none. - Each patch is grouped under the most specific
MAINTAINERSentry it touches. That works well for driver work. For a tree-wide series it means the whole series can end up under whichever driver happens to be most specific, which is why the DRMresetconversion shows up under the ARM Komeda driver and the SCSI locking work under smartpqi. - A series appears once, by its cover letter. The patch count beside it is the number of its patches in linux-next, not the size of the posting.
Thirteen days to go until rc1.