|
|
Log in / Subscribe / Register

6.18 merge window, part 1

By Daroc Alden
October 6, 2025

At the time of writing, there have been 9,099 commits in the 6.18 merge window, 8,475 non-merges and 624 merges. The changes so far include core-kernel, graphics, and networking work, among others. There are no big surprises, but several items that were discussed at this year's LFSMM+BPF Summit have now been merged.

The most significant changes merged so far include:

Architecture-specific

  • The Spectre mitigations for Arm Cortex-A720 CPUs now also apply to Cortex-A720AE CPUs.
  • PowerPC now supports BPF arenas and some associated atomic instructions, as does RISC-V. These instructions allow BPF programs to atomically load and store values in BPF arenas for, among other purposes, asynchronous communication with user space.
  • x86 has gained a microcode= command-line option to control the behavior of the microcode loader. The new option replaces microcode.force_minrev, although it will also cover broader microcode-loader options in the future.
  • The kernel can now use more than 255 CPUs as an x86 guest on FreeBSD version 15.0 or later.
  • The nios2 architecture now supports the clone3() system call.

Core kernel

  • Kernel namespaces (such as network namespaces) can now be referred to using file handles. The use of file handles to refer to pidfds was previously supported; this change extends that support to namespaces.
  • Zswap now uses zsmalloc directly, so the zpool compression-configuration mechanism has been removed.
  • Mixed completion queue event (CQE) sizes are now supported in the same ring buffer. With io_uring's growing complexity, users may want to query for the presence of different capabilities; that is also now supported.

Filesystems and block I/O

  • The bcachefs filesystem has been removed in its entirety.
  • pwritev2() calls can now pass RWF_NOSIGNAL to suppress SIGPIPE signals when writing to disconnected pipes or sockets.
  • Procfs now takes an option to specify the associated PID namespace.
  • Errors about a mounted filesystem exposing data from a different user namespace will soon be visible to users with a recent version of mount.
  • A set of deprecated XFS options has been disabled by default. Several obsolete mount options have also been removed, but online fsck is now enabled by default. Online fsck is no longer considered experimental, and so should be generally usable.
  • A new set of lockless bitmaps will improve the performance of the filesystems that use them.

Hardware support

  • GPIO and pin control: Nuvoton NCT6694 GPIO controllers, Maxim MAX7360 GPIO and pin controllers, AAeon UP board FPGA pin controllers, NVIDIA Tegra186 pin controllers, Renesas RZ/T2H and RZ/N2H controllers, Broadcom STB pin controllers, Qualcomm Glymur pin controllers, and Qualcomm SDM660 LPASS LPI pin controllers.
  • Graphics: Solomon SSD2825 MIPI bridges, Waveshare DSI2DPI bridges, Radxa Ra620 bridges, Realtek RTD2171 bridges, MT8189 Chromebook panels, BOE NV140WUM-N64 panels, SHP LQ134Z1 panels for Dell XPS 9345s, Olimex LCD-OLinuXino-5CTS panels, Samsung AMS561RA01 panels, Hydis HV101HD1 panels, Bestar BSD1218-A101KL68 LCD panels, Ampire AMP19201200B5TZQW-T03 panels, EDT ETML0700Z8DHA panels, Mali G710, G510, G310, Gx15, Gx20, and Gx25 GPUs, Rockchip NPU neural processors, Rockchip RK3576 SoCs, Mayqueen Pixpaper eInk displays, T-HEAD TH1520 GPUs, and Arm Mali CSF-based GPUs (driver written in Rust).
  • Hardware monitoring: Kontron SMARC-sAM67 SoCs, GPD device sensors, Monolithic Power Systems MP29502, MP2869, MP29608, MP5998, MP29612, and MP29816 PWM controllers, various ASUS GAMING WIFI motherboard sensors, Texas Instruments INA700 and INA780 power monitors, NXP P3T1750 temperature sensors, Analog Devices sq24905c hotswap controllers, Renesas RAA228244 and RAA228246 PWM controllers, and Sensirion SHT20 and SHT25 humidity and temperature sensors.
  • Industrial I/O: Tegra 256 GPIO controllers, Loongson-2K0300 GPIO controllers, Amlogic AL113L2 SPI controllers, Atmel SAMA7D65 SPI controllers, and Atmel SAM9x7 SPI controllers.
  • Input: Maxim MAX7360 key switch controllers.
  • Interrupt controllers: Aspeed AST2700 SCU interrupt controllers.
  • Media: OmniVision OV6211 and OG0VE1B sensors.
  • Memory: AMD 0x1a EDAC memory, AMD VersalNET memory controller, and EDAC on ADM Cortex A72 cores.
  • Miscellaneous: Loongson Security Engine, RNG, and TPMs, TI TPS6594 power buttons, TI BQ257xx charger ICs, Lumissil Microsystems IS31FL3236A LED drivers, QNAP MCU status LEDs, Loongson-2K BMC IPMI devices, Nuvoton NCT6694 I2C adapters, Nuvoton NCT6694 socket CANfd controllers, Nuvoton NCT6694 watchdog timers, Nuvoton NCT6694 hardware monitors, Maxim MAX7360 pulse-width modulators, Maxim MAX7360 rotary encoders, Amlogic A4 SPI flash controllers, Intel Bay / Cherry Trail Dollar Cove TI batteries, Analog Devices I3C controllers, Aspeed AST2700 reset controllers, and Qualcomm trusted execution environment controllers.
  • Networking: Huawei 3rd gen NICs, SpacemiT K1 Ethernet MACs, and Qualcomm packet-process engines, Skyworks Si3474 power-sourcing equipment, NXP NETC V4 timer-based PTP clocks, TI PRU ICSSM Ethernet ports, and Allwinner sun55i GMAC200 Ethernet controllers.
  • Power: Maxim MAX77838 power controllers, NXP PF0900 and PF5300 power controllers, Richtek RT5133 power controllers, SpacemiT P1 power controllers, Amlogic S6/S7/S7D power-domain controllers, IMX i.MX91 power-domain controllers, PXA1908 power-domain controllers, AN7583 SoCs, ipq5424 frequency controllers, MT8196 frequency controllers, and AM62D2 frequency controllers.
  • Regulator: NXP PF0900/PF0901/PF09XX regulators, NXP PF5300/PF5301/PF5302 regulators, Richtek RT5133 PMIC regulators, Maxim 77838 regulators, and SpacemiT P1 regulators.
  • SoCs: ESWIN EIC7700 SOCs and Renesas RZ/T2H, RZ/N2H, RZ/T2H, and RZ/N2H SoCs.
  • Sound: Qualcomm PM4125 codecs, TI PCM1754 digital-to-analog converters, TI TAS2783A audio amplifiers, Realtek RT1321, Shanghai FourSemi FS2104/5S auioo amplifiers, Tascam US-144mkII USB sound devices, and Presonus S1824 USB sound devices.
  • Thermal: Renesas RZ/G3S and Renesas RZ/G3E SoCs.

Networking

Security-related

  • The audit subsystem can now handle multiple Linux security modules (LSMs) being enabled at the same time. This is part of other work throughout the LSM subsystem to make multiple simultaneously enabled LSMs work smoothly.
  • The kernel now supports signing BPF programs — although security policies that can take advantage of this are still in progress.
  • Encrypting TCP connections with PSP is now possible as well, with the documentation covering the details.

Virtualization

Internal kernel changes

6.18 is shaping up to be a promising release. While there are no earth-shaking changes, there are a lot of disparate improvements. When the merge window closes, LWN will have a second article on all the changes that were merged after this article was written.


Index entries for this article
KernelReleases/6.18


to post comments

Minor correction, also super excited for the new features!

Posted Oct 7, 2025 9:18 UTC (Tue) by rhbvkleef (subscriber, #154505) [Link]

> * UDP receive performance has also been improved, by 47%, according to Eric Dumazet's measurements.

I'd really like to see it being specified that this test was done under high network load with 120 byte packets.

Overall, I am super excited about this version. I look forward to some features in particular:

* file handles for namespaces
* SPI over virtio. As a heavy user of SPI, I2C, and other similar protocols, being able to pass stuff through to a VM is going to streamline my testing immensely.

Is AccECN finally a viable ECN mechanism?

Posted Oct 7, 2025 23:31 UTC (Tue) by intgr (subscriber, #39733) [Link] (11 responses)

> The work on AccECN, for accurate TCP congestion notification, has been merged.

Interesting! Just recently I read a scathing analysis of classic ECN that concluded "Over the past 6 months of the experiment the ECN-Client rate across the public Internet is relatively small, between 2% and 3% of end clients." https://www.potaroo.net/ispcol/2025-09/ecn-measure.html

It is suspected that this is caused by middlebox interference. If middleboxes haven't gotten their act together wrt ECN for so long, they never will.

As I understand, because AccECN uses space in TCP headers, it's less prone to such interference than classic ECN using IP headers. Is this finally a viable ECN mechanism for the public internet?

Is AccECN finally a viable ECN mechanism?

Posted Oct 8, 2025 0:05 UTC (Wed) by hmh (subscriber, #3838) [Link] (8 responses)

https://blog.tohojo.dk/2025/03/ecn-ecmp-and-anycast-a-coc... for an interesting story about IP-header ECN, and middle-boxes shenanigans...

Is AccECN finally a viable ECN mechanism?

Posted Oct 8, 2025 10:13 UTC (Wed) by paulj (subscriber, #341) [Link] (7 responses)

Good link thanks. Note that seems to be due to a router, which we usually don't consider a "middlebox". Interesting...

Is AccECN finally a viable ECN mechanism?

Posted Oct 8, 2025 11:04 UTC (Wed) by hmh (subscriber, #3838) [Link] (6 responses)

Agreed that routers (as well as switches and switching routers) are not usually classified as "middle-boxes", but ECMP hashing getting the IP fields wrong and not masking out reserved or other-purpose bits (like ECN in the ToS field) *is* the kind of shenanigan you expect from middle-boxes, IMHO. I certainly should have phrased that better.

Network hardware enshitification is a thing just as much as the other kinds of it we commonly observe on the Internet, unfortunately.

Is AccECN finally a viable ECN mechanism?

Posted Oct 8, 2025 13:01 UTC (Wed) by paulj (subscriber, #341) [Link] (5 responses)

It's a really interesting case. The router didn't actually block anything, and it also did not technically misbehave either. It successfully forwarded every packet. It did nothing wrong, as such.

Rather, in this case, it was the destination /system/ that had been designed with the assumption that routers would do per-flow routing, and that anycast of TCP flows would therefore be safe.

It wasn't the middle-box that broke things here, it was the end-host(s).

Is AccECN finally a viable ECN mechanism?

Posted Oct 8, 2025 13:26 UTC (Wed) by hmh (subscriber, #3838) [Link] (4 responses)

Well, I don't quite agree.

Flow hashing has only a *single* purpose for its existence: keeping the packets belong to the same flow in the same network path. Although this is done mostly to avoid reordering packets, when someone uses it to steer load to different UPSTREAM PROVIDERS -- which is an extremely bad idea in the first place -- or in a load balancer to steer *TCP* to different end-hosts, it certainly has to work perfectly or you get all sorts of breakage.

Anyway, as far as I am concerned, that equipment should never have hashed reserved bits, or non-flow-related bits. That hashing is *unfit for ECMP path selection purposes*. Feel free to disagree, but in that case let's just agree to disagree ;-)

Is AccECN finally a viable ECN mechanism?

Posted Oct 8, 2025 14:46 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

If you're aware of an RFC that specifies that all packets from a flow must be routed the same way by an Internet router, be glad to read it and update my understanding. ;) Till then, while I agree with you the behaviour in that blog entry is unusual and not what most (any?) network operators would expect or want, I stick to my understanding that such behaviour is permissible. ;)

Further, even with routers all working according to how you and I would expect, one still can NOT rely on all packets of a flow reaching the same destination in the presence of anycast prefixes. Therefore, the end-destination definitely is *broken* in making that assumption. A calculated risk that works 99+epsilon % of the time sure, and gives benefits when it works, but still... such breakage is to be expected and UNAVOIDABLE even _with all routers doing flow-hashing as we assume_.

Is AccECN finally a viable ECN mechanism?

Posted Oct 8, 2025 15:29 UTC (Wed) by Wol (subscriber, #4433) [Link]

> If you're aware of an RFC that specifies that all packets from a flow must be routed the same way by an Internet router, be glad to read it and update my understanding. ;) Till then, while I agree with you the behaviour in that blog entry is unusual and not what most (any?) network operators would expect or want, I stick to my understanding that such behaviour is permissible. ;)

I think you're talking at cross purposes. I'm certain you're talking about two different things.

Packets from a *flow* are EXplicitly EXpected to take different routes, afaik.

hmh is talking about packets from a *hashed flow*, the purpose of which, I think, is to force them to take the same route.

So if a router encrypts or otherwise messes about with the hashed flow control block, it will really **** things up.

Cheers,
Wol

Anycast and ECMP need flow-consistent routing

Posted Oct 9, 2025 17:30 UTC (Thu) by DemiMarie (subscriber, #164188) [Link] (1 responses)

Otherwise packets would arrive at a server that doesn't know what to do with them.

Anycast and ECMP need flow-consistent routing

Posted Oct 10, 2025 11:10 UTC (Fri) by paulj (subscriber, #341) [Link]

If you advertise the same prefix from multiple different locations, you are telling the Internet "You can deliver matching packets to any of these locations". Indeed, the Internet has 0 way to know that those are different locations, when you tell the global routing system "X is reachable here" from multiple places - to the Internet, those are all the _same place_, so far as it is concerned with the described destination of X. For you told it so.

It is the responsibility of the destination AS to ensure its own internal consistency.

Is AccECN finally a viable ECN mechanism?

Posted Oct 8, 2025 6:40 UTC (Wed) by zdzichu (subscriber, #17118) [Link]

Interesting. I have ECN disabled due to fq_codel being default and this thread: https://lwn.net/Articles/916396/
Maybe it's time to revert to defaults?

Is AccECN finally a viable ECN mechanism?

Posted Oct 10, 2025 9:25 UTC (Fri) by Fowl (subscriber, #65667) [Link]

I would be interested in an Lwn article about AccECN

Support for NPUs in the Graphics section?

Posted Dec 1, 2025 20:05 UTC (Mon) by farooqkz (guest, #180666) [Link] (1 responses)

Hey.

Is there any technical reason NPUs have been mentioned in Graphics section?

First timer in here and kernel in general! Byte me small ;)

Support for NPUs in the Graphics section?

Posted Dec 1, 2025 20:07 UTC (Mon) by corbet (editor, #1) [Link]

The Rockchip neural processing unit appears there because these devices have a lot in common with GPUs and often go upstream via the DRM tree.

See this Maintainers Summit report for some background.


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