Linux 6.18’s Quiet Merge Window Now Runs as LTS

Greg Kroah-Hartman shipped 6.18.55 on October 3, 2026, the latest stable drop of the kernel that still carries last year’s longterm flag. Kernel.org lists Greg and Sasha Levin as maintainers, with a projected EOL of December 2028.

That tree began as Linux 6.18-rc1 on October 12, 2025, after a two-week merge Linus Torvalds later called uneventful on his own test boxes. The second effect of that quiet window is the one that still matters: the code that landed then is the code enterprises, phones, and cloud images will keep patching for years.

Linux 6.18 Is the LTS Kernel Running Into 2028

Greg named 6.18 a longterm series on December 3, 2025, three days after the stable tag. The first public window was two years, through December 2027. On February 25, 2026, after talks with companies and the other stable maintainer, he stretched several longterm trees, and 6.18 moved to at least three years.

THE KERNEL.ORG LONGTERM LIST

6.18 now dies on the same calendar as 6.12. 5.10 and 5.15 are listed only through December 2026, so shops still on those branches have a hard date, not a vibe, for the next move. Kernel.org still warns that projected end dates can move if enough of the industry helps carry a tree.

Torvalds Called It One of the Good Merge Windows

The rc1 mail on October 12, 2025, is almost modest. Size sat in the middle of recent kernels. Nothing in the merge shortlog jumped out. About half the diff was drivers, with the rest spread across vfs, filesystems, architecture work (much of it device tree), tooling, and more Rust.

This was one of the good merge windows where I didn’t end up having to bisect any particular problem on nay of the machines I was testing.

Linus Torvalds, Linux 6.18-rc1 announcement, LKML

He hoped that luck would hold for everyone else. The seven-week candidate stretch that followed ran from October 12 to November 30, 2025, a clean 49 days, and he still groused about last-week noise when he finally tagged the stable kernel. Bluetooth, Ceph, and AFS fixes showed up late, along with a pile of small driver patches, but nothing made him keep the tree in the oven.

THE ROAD FROM RC1 TO LONGTERM

1. October 12, 2025: Torvalds tags 6.18-rc1 and calls it one of the good merge windows.
2. November 30, 2025: He writes that 6.18 is tagged and pushed out after a noisy last week of fixes.
3. December 3, 2025: Greg Kroah-Hartman promotes 6.18 to longterm, first posted through December 2027.
4. February 25, 2026: After talks with companies, the 6.18 window moves to at least three years, through December 2028.
5. October 3, 2026: 6.18.55 ships in a seven-kernel Saturday batch with 7.2.9 and the older longterm lines.

A merge that needed no bisect on Torvalds’s boxes is now a support contract. That is a different kind of success than a flashy rc1 blog post.

DM-PCACHE Puts Persistent Memory in Front of Slow Disks

The storage change that will live longest in this tree is dm-pcache, a device-mapper target from kernel developer Dongsheng Yang. It lets a byte-addressable DAX region, persistent memory or a CXL device, sit in front of a slower block device as a crash-safe cache. The Kconfig help text still calls the module experimental, which is an odd stamp to freeze into an LTS, and operators should treat it that way.

WHAT DM-PCACHE ACTUALLY DOES

• Write-back only: The target accepts write-back and does not yet ship a write-through mode.
• 16 MiB segments: The pmem space is carved into 16 MiB chunks, with per-CPU data heads allocating inside a segment.
• Optional CRC32: Each cache can store a CRC32 on every cached entry and check it on read, or skip the CRC for speed.
• Crash copies: Metadata is duplicated and guarded with CRC plus sequence numbers so a crash does not leave a half-written map.
• Pure DAX path: I/O stays on the DAX path instead of bouncing extra BIOs through the block layer.

Yang’s docs say the design aims at lower latency than Bcache and a similar job to dm-writecache, with random writes several times faster than either in the figures the authors quoted when the code went in. For a database host with persistent memory in the chassis, that is a way to keep NVMe in the back and still absorb the hot write set. Because 6.18 is longterm, those hosts can keep the module without chasing mainline every nine or ten weeks.

Google’s UDP Path Now Drops Floods Without Stalling the Host

The networking work that rode into the same freeze is narrower than a generic “DDoS defense” headline. Google kernel engineer Eric Dumazet sent a net-next series that retunes UDP receive when one or more sockets are under a flood, which is how many volumetric attacks show up on a Linux box.

This series is the result of careful analysis of UDP stack, to optimize the receive side, especially when under one or several UDP sockets are receiving a DDOS attack. I have measured a 47 % increase of throughput when using IPv6 UDP packets with 120 bytes of payload, under DDOS.

Eric Dumazet, Google kernel engineer, net-next patch cover letter

That 47% increase of throughput under DDoS used 16 CPUs feeding a single socket. A later patch in the same effort replaced the old busylock with lockless queues, one per NUMA node, after Dumazet found the lock protected the socket and not the host. On an Intel Xeon 6985P-C with 6 NUMA nodes, the machine processed 14.2 million more packets per second while under attack, and the victim socket took 11% more datagrams (1,116,633 versus 1,004,179 in his nstat snapshot).

Most CPUs can now drop a packet at once or park it on a local queue. One CPU then drains that queue in a batch cooked on the same node. The NIC stops being the thing that silently sheds load while cores spin on a lock. Servers that stay on 6.18 LTS keep that receive path without picking up whatever else mainline grew in 2026.

Tyr, Rocket, and a Haptic Pad Ride the Freeze

Driver traffic was half the rc1 diff, and a few of those new names now have years of backport cover they would not get on a short-lived stable. Tyr is a Rust DRM driver for Arm Mali GPUs, started as a port of Panthor’s user API, and it is not ready for people who just want a desktop to light up. Rocket is the open Rockchip NPU accelerator driver from Tomeu Vizoso, aimed at newer Rockchip SoCs, with user space that was lined up in Mesa 25.3.

Google’s HID work added first-cut haptic touchpad support, targeting the Elan 2703, so a pad with force sensors and actuators can click without a mechanical button. Chrome OS is the reason that code exists. Intel USBIO drivers, more AMD Versal pieces, Wildcat Lake display bring-up, and KVM x86 CET virtualization also came in during the same two weeks.

None of those drivers had to be exciting on October 12, 2025, to matter now. An LTS tree is where a phone SoC vendor, a Mali board, or a Chromebook pad can sit still. The same freeze holds the slub sheaves work and the rest of the 6.18 memory and security upgrades that allocator-heavy and packet-heavy machines actually feel.

Rust Binder landed beside the old C Binder, which is how Android IPC moves between processes. Google can test the new driver against the old one for as long as 6.18 stays alive. That is a nicer lab than a kernel that dies in eight weeks.

Bcachefs Left Before the LTS Clock Started

The merge was calm. The filesystem roster was not. Bcachefs had already been marked externally maintained in 6.17, with the in-tree copy left in place so machines could still boot. For 6.18, Torvalds pulled that copy. The live code moved to a DKMS module, and keeping a stale in-kernel tree would have mixed versions.

Anyone who built bcachefs into 6.17 cannot treat 6.18 LTS as a drop-in. They compile the out-of-tree module, or they pick another filesystem, or they stay on a kernel that still carries the old code. An LTS that ships without bcachefs is a harder line than an rc1 note about a good weekend of testing.

So I’ll have to admit that I’d have been happier with slightly less bugfixing noise in this last week of the release, but while there’s a few more fixes than I would hope for, there was nothing that made me feel like this needs more time to cook. So 6.18 is tagged and pushed out.

Linus Torvalds, Linux 6.18 announcement, LKML, November 30, 2025

XFS, by contrast, turned online fsck on by default in this kernel. Btrfs grew block sizes larger than the page size. The trees that stayed in mainline get the longterm hose. The one that left does not.

Point Release 6.18.55 Landed on October 3

On October 3, 2026, Greg announced 7.2.9, 6.18.55, 6.12.112, 6.6.158, 6.1.189, 5.15.222, and 5.10.271 together. Mainline stable is already in the 7.2 line. 6.18 is the newest longterm in that batch, still taking the same Saturday firehose of backports as trees that launched in 2020.

Rolling distros have not waited. Slackware-current moved off 6.18.52 onto 7.2.7 and said it would track 7.x until the next longterm. That is the rational move for a tree named current. The rational move for a five-year laptop image is the opposite.

GrapheneOS said an upcoming Motorola flagship with official support will start on Linux 6.18, then move to the latest LTS after launch and stay there. A phone that boots on this kernel is why a haptic pad, a Mali Rust stub, and a Rockchip NPU driver were worth merging in a window Torvalds found boring.

10th gen Pixels started out on the 6.6 LTS so they didn't have as far to go to 6.12. 11th gen started on 6.12.

Upcoming Motorola flagship with official GrapheneOS support is starting on Linux 6.18. We'll update it to the latest LTS release after launch and will keep it there.

— GrapheneOS (@GrapheneOS) October 1, 2026

Cloud images tell the same split. Free trial VMs and helper hosts still show 6.18.x in the wild, because a longterm kernel is what you give a stranger’s workload when you do not want to explain a 7.3-rc. The people who chase features have left. The people who ship devices have not.

6.18.55 does not add dm-pcache, Tyr, or Dumazet’s queues. Those already shipped on November 30, 2025. What it adds is another week of proof that the quiet merge is still the branch Greg signs, and that kernel.org still prints December 2028 next to the name.