The second half of the 6.16 merge window
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
- The getrandom() system call is now much faster on RISC-V. It is now handled entirely within the vDSO.
- RISC-V kernels now support new vendor extensions from SiFive, as well as the Zicbop, Zabha, and Svinval extensions. They also include the supervisor binary interface (SBI) firwmare features (FWFT) extension, which is needed for SBI 3.0, the latest version.
- LoongArch now supports up to 2048 CPUs, the maximum that the architecture can handle. The architecture now also has multi-core scheduling.
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
- The contents of device memory can now be sent via TCP, allowing zero-copy transmission from a GPU to the wire.
- BPF can be used to implement traffic-control queueing disciplines (qdiscs) with a struct_ops program.
- Support for the datagram congestion control protocol (DCCP) is being removed following a long deprecation and no signs of having any users. DCCP was intended to prevent problems with UDP's lack of rate control, which have largely failed to materialize. It was originally added in 2005. The hope is that this removal will enable cleanup of the parts of the TCP stack that are currently shared with DCCP.
- The kernel now supports using generic security services application programming interface (GSSAPI) for the AFS filesystem, allowing connections to manage the encryption of connections to YFS and OpenAFS servers.
- OpenVPN now has a virtual driver for offloading some operations to the kernel, which should make it faster, especially for large transfers.
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 | |
---|---|
Kernel | Releases/6.16 |
Posted Jun 9, 2025 21:36 UTC (Mon)
by geofft (subscriber, #59789)
[Link] (3 responses)
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?
Posted Jun 10, 2025 4:32 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Yes, like with the original SoundBlaster!
Posted Jun 10, 2025 9:41 UTC (Tue)
by hadess (subscriber, #24252)
[Link]
Posted Jun 10, 2025 10:44 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
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.
Posted Jun 10, 2025 9:51 UTC (Tue)
by jic23 (subscriber, #56049)
[Link] (2 responses)
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
Posted Jun 10, 2025 12:45 UTC (Tue)
by daroc (editor, #160859)
[Link] (1 responses)
Posted Jun 11, 2025 7:04 UTC (Wed)
by jic23 (subscriber, #56049)
[Link]
USB audio offloading
USB audio offloading
USB audio offloading
https://docs.kernel.org/sound/designs/compress-offload.html
It's not hugely meaningful for non-USB audio cards; for ones with "real" DMA, it already happens.
USB audio offloading
IIO pull had a few more drivers
IIO pull had a few more drivers
IIO pull had a few more drivers