|
|
Subscribe / Log in / New account

The second half of the 6.16 merge window

By Daroc Alden
June 9, 2025

The 6.16 merge window closed on June 8, as expected, containing 12,899 non-merge commits. This is slightly more than the 6.15 merge window, but well in line with expectations. 7,353 of those were merged after the summary of the first half of the merge window was written. More detailed statistics can be found in the LWN kernel source database.

As usual, the second half of the merge window contained more bug fixes than new features, but there were many interesting features that made their way in as well:

Architecture-specific

Core kernel

  • Unix-domain sockets can be used to transfer file descriptors; it is now possible for a program to opt-out of that ability, which may be important to preventing denial-of-service attacks.
  • The ring buffer used for kernel tracing can now be mapped into memory in user space.
  • A new API will let virtual memory allocations persist across kexec handovers.
  • Crash-dump kernels (the special kernel that runs after a kernel crash to produce a report) can now reuse existing LUKS keys. This lets crash dumps be made to encrypted filesystems, which was not previously possible.
  • The kernel memory accounting done by the memory control-group code can now be performed in a non-maskable interrupt (NMI) context. This is important because BPF programs can run in NMI contexts, and may need to allocate memory in the kernel, which in turn needs to be accounted for.
  • NUMA weighted interleaving is now automatically tuned, providing better utilization of memory bandwidth in systems with data striped across multiple NUMA nodes.

Filesystems and block I/O

  • OrangeFS now makes use of the new mount API, as does UFS.
  • The limit on read and write sizes for NFS filesystems has been raised to 4MB. "The default remains at 1MB, but risk-seeking administrators now have the ability to try larger I/O sizes with NFS clients that support them."
  • Users with the CAP_SYS_ADMIN capability in a user namespace (and no privileges in the root namespace) can now watch filesystems and mounts with fanotify.
  • The ext2 filesystem has deprecated support for DAX, since it isn't widely used. The ext2 filesystem itself isn't widely used either, but it does serve as a stable reference implementation of a filesystem. Since persistent memory has not become as widely used as once expected, supporting it in a reference implementation doesn't make much sense. DAX support in ext2 is expected to be completely removed at the end of 2025.
  • FUSE filesystems can now invalidate all existing cached directory entries (dentries) in a single operation.
  • The overlayfs filesystem now supports data-only layers with dm-verity in user namespaces. This allows trusted metadata layers to be combined with untrusted data layers in unprivileged namespaces.

Hardware support

  • Clock: SpacemiT K1 SoCs, Sophgo SG2044 SoCs, T-HEAD TH1520 video-output clocks, Qualcomm QCS8300 camera clocks, Allwinner H616 display-engine clocks, Samsung ExynosAutov920 CPU cluster clock controllers, Renesas RZ/V2N R9A09G056 SoCs, Sophgo CV1800 clocks, and NXP S32G2/S32G3 clocks.
  • GPIO and pin control: Mediatek MT6893 and MT8196 SoCs, Renesas RZ/V2N SoCs, MediaTek Dimensity 1200 (MT6893) I2C, Sophgo SG2044 I2Ci, Renesas RZ/V2N R9A09G056 I2C, Rockchip RK3528 I2C, and NXP Freescale i.MX943 SoCs.
  • Graphics: Amlogic C3 image-signal processors.
  • Hardware monitoring: Dasharo fans and temperature sensors, KEBA fan controllers and battery monitoring controllers, MAX77705 ICs, MAXIMUS VI HERO and ROG MAXIMUS Z90 Formula motherboards, SQ52206 energy monitors, lt3074 linear regulators, ADPM12160 DC/DC power modules, and MPM82504 and MPM3695 DC/DC power modules.
  • Industrial I/O: DFRobot SEN0322 oxygen sensors.
  • Input: ByoWave Proteus game controllers and Apple Magic Mouse 2s.
  • Media: ST VD55G1 and VD56G3 image sensors and OmniVision OV02C10 image sensors.
  • Miscellaneous: FSL vf610-pit periodic-interrupt timers, SGX vz89te integrated sensors, Maxim max30208 temperature sensors, TI lp8864 automotive displays, MT6893 MM IOMMUs, Sophgo CV1800 and SG2044 SoCs, Qualcomm sm8750 SoCs, Amlogic c3 and s4 SoCs, and Renesas RZ/V2H(P) R9A09G057 DMA controllers.
  • Networking: Renesas RZ/V2H(P) SoC, Broadcom asp-v3.0 ethernet devices, AMD Renoir ethernet devices, RealTek MT9888 2.5G ethernet PHYs, Aeonsemi 10G C45 PHYs, Qualcomm IPQ5424 qusb2 PHYs, IPQ5018 uniphy-pcie devices, Mediatek MT7988 xs-PHYs, and Renesas RZ/V2H(P) usb2 PHYs.
  • Sound: Fairphone FP5 sound card.

Miscellaneous

  • Support for the STA2x11 video input port driver has finally gone away.
  • The documentation generation script scripts/bpf_doc.py can now produce JSON output about BPF helpers and other elements of the BPF API. This change makes it easier for external tools to keep their knowledge of the BPF interface up to date.
  • Writing "default" to the sysfs trigger of an LED device will now reset the trigger to that device's default.
  • Compute express link (CXL) devices now support the reliability, availability, and serviceability (RAS) extensions. Most importantly, these let CXL devices participate in various error detection and correction schemes.
  • This release includes a number of improvements to perf, including support for calculating system call statistics in BPF, better demangling of Rust symbols, more granular options for collecting memory statistics, a flag to deliberately introduce lock contention, and several more.
  • USB audio devices now support audio offloading. This lets, for example, audio from a USB device to continue to flow even when the rest of the system is sleeping. In the pull request, Greg Kroah-Hartman said: "I think this takes the record for the most number of patch series (30+) over the longest period of time (2+ years) to get merged properly."

Networking

Security-related

  • The randstruct GCC plugin, which makes it harder for attackers to access kernel data structures by randomizing their layout, is now working again, and has tests to keep it that way. The ARM_SSP_PER_TASK GCC plugin, which lets different tasks use different stack canaries, has been retired, since its functionality is available in upstream GCC.
  • Integrity Measurement Architecture (IMA) measurements can now be carried across kexec invocations. A new kernel-configuration option, IMA_KEXEC_EXTRA_MEMORY_KB determines how much memory is set aside for new IMA measurements on a soft reboot.
  • The measurements made by the trusted security manager (TSM; part of Intel's trust domain extensions, also known as TDX) are now exposed as part of sysfs. This gives user space the opportunity to make decisions based on attestations from the hardware.
  • The performance overhead of SELinux has been reduced by adding a cache for directory-access decisions and support for wildcards in genfscon policy statements.
  • The kernel's EFI code has been extended to allow emitting a .sbat section with UEFI SecureBoot revocation information; the upstream kernel project won't maintain the revocation information, but individual distributions now have the access they need to the be able to ship their own revocation databases.
  • The .static_call_sites section in loadable modules is now made read-only after module initialization.

Virtualization and containers

  • 64-Bit Arm now supports transparent huge pages on non-protected guests when protected KVM is enabled.
  • Nested virtualization support on 64-bit Arm is also working, although it remains disabled by default.
  • x86 virtual machine hosts on KVM now support TDX, enabling the use of confidential guests on Intel processors. This change "has been in the works for literally years", and includes a large number of patches.
  • KVM support on RISC-V is no longer experimental.

Internal kernel changes

  • The power-management subsystem has gained Rust abstractions for managing CPU frequency, operating performance points (OPPs), and related power-management APIs.
  • The kernel's minimum supported GCC version has been updated to GCC 8 for all architectures; the update allows for two of the five remaining GCC plugins used in kernel builds to be removed. The corresponding minimum version of binutils is 2.30.
  • A bevy of memory-management changes includes more folio conversions, Rust abstractions for core memory-management operations, better support for memory compaction, and the removal of VM_PAT.
  • Rust test error messages are now more tightly integrated into KUnit when using assertions and results. Rust code can now also make use of XArrays.

The 6.16 kernel now goes into the stabilization period, with the final release expected July 27 or August 3.


Index entries for this article
KernelReleases/6.16


to post comments

USB audio offloading

Posted Jun 9, 2025 21:36 UTC (Mon) by geofft (subscriber, #59789) [Link] (3 responses)

I'm trying to understand how the USB sound changes for audio offloading work and how I might use it.

Is the idea that the audio playback application places the audio in host RAM in (uncompressed) PCM format, and you tell the device where it is, and then the host CPUs can sleep as long as the sound card and RAM remain powered and the sound card can do DMA?

(I guess this is kind of like the effect where if my system kernel panics, some sound devices will loop the last half-second of audio rather unpleasantly because presumably they have a ring buffer and it stopped getting updated. I guess this allows a much longer, non-ring buffer for audio?)

Is this a sensible thing for the virtio sound device to do, so you can play music out of a VM without any of the CPU threads waking up? I guess that's not USB, so the broader question is, is this meaningful for non-USB sound cards? Maybe it already happens?

USB audio offloading

Posted Jun 10, 2025 4:32 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

> Is the idea that the audio playback application places the audio in host RAM in (uncompressed) PCM format, and you tell the device where it is, and then the host CPUs can sleep as long as the sound card and RAM remain powered and the sound card can do DMA?

Yes, like with the original SoundBlaster!

USB audio offloading

Posted Jun 10, 2025 9:41 UTC (Tue) by hadess (subscriber, #24252) [Link]

ALSA has a generic API for this since 2011:
https://docs.kernel.org/sound/designs/compress-offload.html

USB audio offloading

Posted Jun 10, 2025 10:44 UTC (Tue) by farnz (subscriber, #17727) [Link]

It's not hugely meaningful for non-USB audio cards; for ones with "real" DMA, it already happens.

USB data is pushed by the host, not pulled by the device; you need something to push data to keep the buffer full but not overflowing. PCIe, AHB, virtio etc allow devices to pull data from the host buffer via DMA, and thus make the device responsible for keeping its internal buffer full.

Some chips have a specialised processor embedded that can do just enough USB audio to handle the buffer transfer stuff, doing what a PCIe device would do via DMA, and that's what this enables - that specialized processor can now track buffer state on the device, handle feedback messages or send timestamps depending on the USB audio clock mode, and send data to keep the buffer in the USB audio device from either overflowing or underflowing.

IIO pull had a few more drivers

Posted Jun 10, 2025 9:51 UTC (Tue) by jic23 (subscriber, #56049) [Link] (2 responses)

Hi Daroc,

Felt like a busy cycle for me so I checked. At least 3 more completely new drivers, and a bunch of extra devices support on existing drivers.

https://lore.kernel.org/all/20250521143159.097d9b52@jic23...

Bit buried below a bunch of core changes so fair enough to have missed some of them!

Thanks

IIO pull had a few more drivers

Posted Jun 10, 2025 12:45 UTC (Tue) by daroc (editor, #160859) [Link] (1 responses)

Oops, I did miss those. I'll keep a closer eye out for the next merge window. Thanks for pointing them out!

IIO pull had a few more drivers

Posted Jun 11, 2025 7:04 UTC (Wed) by jic23 (subscriber, #56049) [Link]

No problem. Thanks for the mammoth effort needed to track all this!


Copyright © 2025, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds