Linux 7.3-rc1 dropped Saturday. One thousand two hundred and fifty memory management patches.

Linus tagged 7.3-rc1 on Saturday. Two-week merge window is closed. The tree sits at roughly 41 million lines of code and is now baking through however many rc cycles it needs before October. Here is what actually landed.

The memory management number

1,250 patches to memory management. The previous cycle took 920. That number by itself is not alarming — the MM subsystem is enormous and touches everything — but 1,250 patches in a single merge window says someone has been holding work, or several someones have. Core MM updates, memblock, the slab allocator, memory hotplug paths. If regressions surface in your distro kernel over the next few months and something breaks on a large-memory NUMA box, this is where to start looking.

I have been watching kernel development since before most current contributors were born. A merge window with 35% more MM patches than the previous cycle is either a sign that the subsystem had serious debt to pay down, or a sign that coordination broke this cycle and work got batched. Possibly both. The test suite will surface regressions, distros will backport fixes, the stable queue will be full. It is how it works. It does not make the number less interesting.

NTFS3: security fixes and also, about those Alternative Data Streams

Two separate things happened to NTFS3 in this merge window. They deserve separate reactions.

The security fixes: a 21-commit, 922-line patch set covering slab-out-of-bounds writes, out-of-bounds reads during INDEX_ROOT parsing for reparse and objid init, information leaks in ntfs_rename(), and integer overflows in MFT cluster validation. These are real bugs. Slab-out-of-bounds on filesystem data is the kind of thing that gives kernel security teams a rough few weeks. The fixes are good. The fact that the bugs existed in code that handles data from Windows-formatted drives that real systems mount is the part worth noting.

NTFS3 ships in mainline. It is what you get when you mount a Windows drive. When it has slab-out-of-bounds writes, they are reachable from disk data that you do not control. Patch your kernel. Run a current stable.

The other thing: NTFS3 now supports Alternative Data Streams. ADS is the NTFS mechanism for attaching named secondary data streams to a file using colon notation in the filename: file.txt:hidden_stream. Zone Identifier streams are how Windows marks files downloaded from the internet. Some Windows backup applications use ADS for metadata. It is, to put it diplomatically, a very Windows concept.

It is now in the Linux kernel. You can parse ADS from an NTFS volume on a Linux host. The implementation handles the colon delimiter and UTF-16 name conversion. This is reasonable behavior if your job involves working with Windows filesystems from Linux, and a lot of people have that job. I am going to note, without further editorializing, that we have added a Windows-specific metadata stream format to the Linux kernel because the world is what it is, and then we are going to move on.

Rust on PowerPC

PowerPC now has in-kernel Rust support. Both PPC32BE and PPC64LE, with specific focus on IBM Power12. This joins ARM32, ARM64, LoongArch, RISC-V, UM, and x86_64 on the supported list.

I will say this out loud: the Rust-in-kernel effort has been more disciplined than I expected when it started. The scope has stayed focused on new drivers and infrastructure where memory safety properties actually matter. The kernel core has not been rewritten in anything. The people doing it have been patient about the build system integration. I still do not particularly want to write Rust. I am grudgingly less worried about the kernel having Rust in it than I was a few years ago. The PowerPC enablement is not surprising; it is methodical. That is actually the compliment.

KVM and the rest

KVM got a structural overhaul this cycle. The details are in the merge request, but the short version is that the virtualization layer has been accumulating technical debt across architecture-specific paths and this merge window paid some of it down. If you run KVM hypervisors, watch the rc cycle for regressions on your specific hardware path.

Btrfs performance improvements landed, which is true in approximately every kernel release, but this cycle the work focused on free space handling and the benchmarks have noticed. AMD Zen 6 additions, Intel hybrid CPU scheduling optimizations, and the sched_ext sub-scheduler support is now flagged feature-complete in 7.3, meaning the BPF scheduler framework can spawn sub-schedulers for specific task classes if you want that level of control.

7.3 stable is expected mid-October if the rc cycle is clean. With 1,250 MM patches in the tree, I would not assume the rc cycle is going to be clean.

See also: You can write a CPU scheduler in BPF now for what sched_ext actually is and why the feature-complete flag matters, and landlock unprivileged sandboxing for tightening process isolation on the hosts that will be running these kernels.