The first half of the 6.6 merge window

As of this writing, 4,588 non-merge changesets have been pulled into the mainline repository for the 6.6 kernel release. The 6.6 merge window, in other words, is just getting started. Nonetheless, a fair amount of significant work has already been pulled, so the time has come to summarize what has happened so far in this development cycle.

Interesting changes pulled for 6.6, to date, include:

Architecture-specific

• The PA-RISC architecture has gained a just-in-time BPF compiler.

Core kernel

• The /sys/devices/system/cpu/smt/control knob has, until now, only been able to accept two values: on to turn simultaneous multithreading ("hyperthreading") on, or off to disable it. This knob has been enhanced to also accept a numeric value indicating the number of threads that should be enabled per core. Initially this feature will be used by the PowerPC architecture, which can (in some CPUs) run up to 16 threads in each core.
• The earliest eligible virtual deadline first (EEVDF) CPU scheduler has been merged; it should provide better performance and fairness while relying less on fragile heuristics. The merge message notes that there may be some rare performance regressions with some workloads, and that work is ongoing to resolve them.

Filesystems and block I/O

• There is a new flag, FSCONFIG_CMD_CREATE_EXCL, for the mount API; if it is present, it prevents a mount from sharing an in-kernel superblock with another mount. As explained in this commit, superblock sharing can result in mount options being ignored, which can lead to security problems. The intent is to enable the addition of a new --exclusive flag to the mount command so that administrators can request that superblock sharing not be allowed.
• The virtual filesystem layer now supports fine-grained timestamps on files. As described in this article, these timestamps allow filesystems like NFS to detect changes quickly for correct cache management while minimizing the overhead of maintaining timestamps in general. Currently fine-grained timestamps are supported by the Btrfs, ext4, tmpfs, and XFS filesystems.
• The tmpfs filesystem has gained a number of features, including quota support, user extended attributes, direct I/O, and stable directory offsets (fixing a problem with filesystems exported via NFS).
• The kernel will no longer allow the changing of permissions on symbolic links.
• The fchmodat2() system call has been added. This version supports the flags argument that is defined as part of fchmodat(), but which has never been supported by Linux. This new system call will enable the removal of some inelegant hacks that were needed by C libraries to implement the missing functionality. This merge message describes the currently supported flags.
• The erofs filesystem has gained a bloom filter that speeds up negative extended-attribute lookups and support for the Deflate compression algorithm.
• The XFS filesystem has gained the ability to use large folios in the page cache and some associated optimizations, all of which should improve performance significantly for some workloads.
• It is now possible to build a kernel without buffer-head support, though doing so greatly restricts the filesystems that are available. This is part of the ongoing effort to get rid of — or at least greatly reduce — the use of buffer heads in the kernel.
• The ublk user-space block driver has gained (undocumented) support for zoned-storage devices.

Hardware support

• GPIO and pin control: ADI DS4520 I2C-based GPIO expanders.
• Hardware monitoring: Renesas HS3001 humidity and temperature sensors.
• Miscellaneous: Loongson SPI controllers and Cirrus Logic CS42L43 SPI controllers.
• Networking: Broadcom ASP 2.0 Ethernet controllers, Marvell 88Q2XXX PHYs, and TI PRU ICSS Industrial Ethernet peripherals.
• Regulator: Qualcomm REFGEN voltage regulators, ADI MAX77857/MAX77831 regulators, Richtek RTQ2208 SubPMIC regulators, and Awinic AW37503 dual output power regulators.

Miscellaneous

• The kernel has moved forward to Rust 1.71.1 and bindgen 0.65.1. There have been a number of changes to low-level utilities; see this merge message for the details.

Networking

• The AF_XDP address family has gained the ability to deal with packets stored in multiple buffers; this changelog and this documentation patch have a fair amount of detail on how it works.
• There is a new BPF hook into packet defragmentation that makes it easier to see (and filter) complete packets; this merge message has a little more information.
• A new BPF hook (update_socket_protocol) allows a BPF program to change the requested protocol for a new socket. Its primary purpose seems to be to transparently cause programs requesting TCP connections to use multipath TCP instead. MPTCP has also gained some initial support for BPF programs that route packets to different subflows.
• The io_uring subsystem has gained partial support for network operations, though the full set will wait until the 6.7 cycle.

Security-related

• The seccomp() system call has gained a new flag (SECCOMP_USER_NOTIF_FD_SYNC_WAKE_UP) that indicates that events from the watched process will be handled synchronously; that allows the kernel to schedule the two processes more efficiently.
• The kmalloc() randomness patches have been merged. This work adds a bit of entropy to memory allocations, making exploits a bit harder.
• The SELinux subsystem, formerly "NSA SELinux", has been "de-branded". "While NSA was the original primary developer and continues to help maintain SELinux, SELinux has long since transitioned to a wide community of developers and maintainers".

Virtualization and containers

• The userfaultfd() system call has gained a new operation, UFFDIO_POISON, that can mark pages as being poisoned. The use case here is in virtual-machine migration; if a memory page has been corrupted (and thus "poisoned") on the old system, userfaultfd() can be used to retain that marking on the new system.

Internal kernel changes

• The "kunit" unit-testing framework can now run the Rust documentation tests along with the rest.
• The Frontswap mechanism was added to the kernel in 2010. In 2023, it's removal is now complete.
• The struct ptdesc patches have been merged. They take the page-table-related fields of struct page and split them into a separate structure, continuing the process of separating the various uses of struct page.
• A change to internal symbol handling was merged to make it harder for proprietary modules to bypass restrictions on GPL-only symbols.
• The dynamic software I/O TLB patch series has been merged, providing better support for devices that, for one reason or another, need to use bounce buffering.

The 6.6 merge window can be expected to remain open through September 10, after which the development community will spend seven or eight weeks stabilizing all of this work. As always, LWN will catch up with the rest of the merge window once it closes.

Index entries for this article
Kernel	Releases/6.6

---

to post comments

The first half of the 6.6 merge window

Posted Aug 31, 2023 16:45 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

> A new BPF hook (update_socket_protocol) allows a BPF program to change the requested protocol for a new socket. Its primary purpose seems to be to transparently cause programs requesting TCP connections to use multipath TCP instead. MPTCP has also gained some initial support for BPF programs that route packets to different subflows.

It seems like this functionality should be represented via a normal prctl() option, rather than via ad-hoc BPF hooks.

The first half of the 6.6 merge window

Posted Sep 20, 2023 11:40 UTC (Wed) by ghane (guest, #1805) [Link] (4 responses)

Is MP-TCP in actual use on the public internet? I am not aware of any deployments except test beds.

Information welcome.

--
Sanjeev

The first half of the 6.6 merge window

Posted Sep 20, 2023 20:48 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Apple uses it for Siri: https://www.tessares.net/apples-mptcp-story-so-far/

The first half of the 6.6 merge window

Posted Sep 20, 2023 23:36 UTC (Wed) by Fowl (subscriber, #65667) [Link] (1 responses)

I’d be surprised if they hadn’t moved to or at least planned to add QUIC/HTTP3.

Wonder how long until we see that in the kernel. SMB3 has a QUIC transport now, for example. Perhaps even the first(?) io_uring exclusive user space API - at least on the server - the browser people like to keep control. /musings

The first half of the 6.6 merge window

Posted Sep 23, 2023 21:06 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

It still uses it.

Siri has to work with all kinds of crappy hotel networks, so QUIC is not an option. It relies on UDP which is frequently blocked. MP-TCP is basically just TCP, so it works everywhere.

The first half of the 6.6 merge window

Posted Sep 23, 2023 8:28 UTC (Sat) by mupuf (subscriber, #86890) [Link]

We used it to broadcast cycling competitions over the 4G network in Finland. Each motorcycle-mounted camera had four 4G modems with SIM cards from different providers.

Worked wonderfully well! It was good-enough for live national TV too :)

PA-RISC?

Posted Aug 31, 2023 18:27 UTC (Thu) by kschendel (subscriber, #20465) [Link]

> The PA-RISC architecture has gained a just-in-time BPF compiler.

That woke me up. I thought PA-RISC was EOL'ed ages ago. I guess there are still machines and users?

I always thought that the architecture deserved better than HP support and HP-UX. (I'll restrain myself from the usual misspelling.)

The first half of the 6.6 merge window

Posted Aug 31, 2023 20:10 UTC (Thu) by willy (subscriber, #9762) [Link]

> The XFS filesystem has gained the ability to use large folios in the page cache and some associated optimizations, all of which should improve performance significantly for some workloads

XFS has been using large folios in the page cache since May 2021 (merged into v5.17). What's changed here is the ability to create large folios for cached writes. Previously, large folios were only created by read() or mmap().

The patches from Ritesh aren't exactly associated. His motivation was random-write workloads with a block size < PAGE_SIZE, almost the exact opposite problem. It's purely scheduling that they ended up in the same git pull.

The first half of the 6.6 merge window

Posted Aug 31, 2023 23:36 UTC (Thu) by th0ma7 (guest, #24698) [Link] (3 responses)

> The kernel will no longer allow the changing of permissions on symbolic links.

Wouldn't this affect user space?

Changing permissions on symbolic links

Posted Aug 31, 2023 23:45 UTC (Thu) by corbet (editor, #1) [Link] (2 responses)

No, I would not expect this change to affect user space. Most filesystems already do not allow symlink permissions to be changed, and those permissions are meaningless in any case.

Note that we're not talking about changing permissions on the target of a symlink, only the symlink itself.

Changing permissions on symbolic links

Posted Sep 1, 2023 13:39 UTC (Fri) by eru (subscriber, #2753) [Link] (1 responses)

Has it even been possible to express the operation of changing symlink permissions? "chmod symlink" dereferences the link to the thing it points to.

Changing permissions on symbolic links

Posted Sep 1, 2023 13:48 UTC (Fri) by corbet (editor, #1) [Link]

fchmodat() can do that; see this article from July.

The first half of the 6.6 merge window

Posted Aug 31, 2023 23:53 UTC (Thu) by jalla (guest, #101175) [Link]

half expected this to be dominated by bcachefs. still pretty excited to see it be as far as it is, and it hopefully making it into experimental

The first half of the 6.6 merge window

Posted Sep 1, 2023 14:56 UTC (Fri) by gray_-_wolf (subscriber, #131074) [Link] (11 responses)

I am curious, should we expect the rust version to change often? GCC is still sufficient in 5.1 (pretty old) for example.

Packaging firefox is sometimes a fun exercise in getting it build with the version of rust you have on hand. Should the same be expected from the kernel or is this just a temporary thing and the rust version required will stabilize one day and be not increased this often?

I do not know much about rust backwards compatibility story...

The first half of the 6.6 merge window

Posted Sep 1, 2023 15:07 UTC (Fri) by willy (subscriber, #9762) [Link] (10 responses)

https://rust-for-linux.com/rust-version-policy

The first half of the 6.6 merge window

Posted Sep 7, 2023 2:51 UTC (Thu) by milesrout (subscriber, #126894) [Link] (9 responses)

That doesn't answer the question. It says "It remains to be decided how often the Rust version upgrades will land. Ideally we would track the latest Rust release, but it remains to be seen how other kernel developers feel about it." What is the actual policy?

Putting a language into the kernel that is so unstable that the "ideal" solution is to track the *latest release* is so insane I can't believe it's being seriously considered.

The first half of the 6.6 merge window

Posted Sep 7, 2023 16:18 UTC (Thu) by angelsl (subscriber, #144646) [Link] (2 responses)

Why does it being ideal that the latest Rust version is used imply that Rust is unstable?

It's not. It's perfectly fine to stay on some fixed version. But Rust is still getting new features that make it more ergonomic especially for low-level development like the kernel and people want to use those features.

The first half of the 6.6 merge window

Posted Sep 7, 2023 22:22 UTC (Thu) by gray_-_wolf (subscriber, #131074) [Link] (1 responses)

Doesn't that increase the difficulty of using newer kernel on older distribution? I feel there is a difference between difficulty of backporting a new kernel and backporting a new kernel and all the required rust machinery, since the version my distro has can no longer build the current kernel.

In the same vein, I am sure gcc has nice features people would like to use in at least some versions between 5.1 (minimal requirement) and 13.2 (current version).

I am unsure why there is (or will be) difference in policy between those two compilers.

The first half of the 6.6 merge window

Posted Sep 11, 2023 18:08 UTC (Mon) by ojeda (subscriber, #143370) [Link]

> Doesn't that increase the difficulty of using newer kernel on older distribution? I feel there is a difference between difficulty of backporting a new kernel and backporting a new kernel and all the required rust machinery, since the version my distro has can no longer build the current kernel.

Distributions can ignore Rust for the time being if they wish to do so. Some distributions, when I checked with them, told me they would be happy to provide a package (or support in some other way) to compile the kernel with the latest Rust release, assuming they need it.

Ubuntu, for instance, offers experimental support for it, by providing a package with the required Rust toolchain.

> In the same vein, I am sure gcc has nice features people would like to use in at least some versions between 5.1 (minimal requirement) and 13.2 (current version).
>
> I am unsure why there is (or will be) difference in policy between those two compilers.

There is definitely a difference nowadays; however, the plan is to remove that difference as soon as it is possible/reasonable. Please see this section in the webpage: https://rust-for-linux.com/rust-version-policy#after-a-minimum-version-is-declared.

The first half of the 6.6 merge window

Posted Sep 11, 2023 18:06 UTC (Mon) by ojeda (subscriber, #143370) [Link] (5 responses)

> That doesn't answer the question. It says "It remains to be decided how often the Rust version upgrades will land. Ideally we would track the latest Rust release, but it remains to be seen how other kernel developers feel about it." What is the actual policy?

It does answer the questions that gray_-_wolf posed.

As the webpage mentions, we are currently trying out upgrading to the latest Rust release as they land. So far, it has not been a problem for the kernel developers using Rust.

But, to be clear, as the webpage also says, this is just the policy before we can establish a minimum version. Being in the latest one will make it much easier to establish so when it happens, it makes development easier and allows us to give feedback to the Rust teams on the unstable features we need.

> Putting a language into the kernel that is so unstable that the "ideal" solution is to track the *latest release* is so insane I can't believe it's being seriously considered.

The Rust language is stable. Some features we need are not. I will add a note to the webpage to make it clear that Rust promises backwards compatibility (for the stable language).

And it is not an ideal solution: the webpage makes it clear that in the end we want to establish a policy similar to GCC, Clang or other tools used in the kernel.

The first half of the 6.6 merge window

Posted Sep 11, 2023 18:34 UTC (Mon) by pizza (subscriber, #46) [Link] (4 responses)

> The Rust language is stable. Some features we need are not.

That strikes me as a distinction without a difference.

The first half of the 6.6 merge window

Posted Sep 11, 2023 19:25 UTC (Mon) by mb (subscriber, #50428) [Link] (3 responses)

Do you want to wait for all the gcc extensions used by the kernel to land in an official C standard before you can use such a kernel?
It's the same thing.

The first half of the 6.6 merge window

Posted Sep 11, 2023 20:32 UTC (Mon) by pizza (subscriber, #46) [Link] (2 responses)

> Do you want to wait for all the gcc extensions used by the kernel to land in an official C standard before you can use such a kernel? It's the same thing.

It's only the same thing if each kernel release required you to use the latest release of GCC because "C is stable but the features we need are not."

(Meanwhile, the kernel only requires GCC 5.1, which was released over eight years ago. So.. yeah, not the same thing at all)

The first half of the 6.6 merge window

Posted Sep 12, 2023 6:03 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Some kernel features like control flow integrity checking or shadow stacks (just merged) require a much newer GCC.

Yes, Rust is even newer than that. But that's a distinction without a difference: some kernel features require very new toolchains.

The first half of the 6.6 merge window

Posted Sep 12, 2023 6:17 UTC (Tue) by mb (subscriber, #50428) [Link]

Correct.
Some Distributions even used to ship a special gcc compiler just for compiling the kernel.
The kernel has very special requirements. That's true for C and Rust alike.
And I really don't see why that would be a problem.

The first half of the 6.6 merge window

Posted Sep 4, 2023 1:12 UTC (Mon) by shenki (subscriber, #49715) [Link] (1 responses)

> the PowerPC architecture, which can (in some CPUs) run up to 16 threads in each core.

This should be 8, I don't think there are any SMT16 CPUs.

PPC CPU threads

Posted Sep 4, 2023 1:41 UTC (Mon) by corbet (editor, #1) [Link]

That number came from this merge message (from the pull request). If I was wrong, it's a copy-and-paste error :)