|
|
Subscribe / Log in / New account

The first half of the 6.1 merge window

Please consider subscribing to LWN

Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.

By Jonathan Corbet
October 7, 2022
The 6.1 merge window is well underway: since it opened, 5,752 non-merge changesets have been pulled into the mainline repository. That is approximately half of the work that had piled up in linux-next and marks a good time to look at what has been merged so far. Some long-awaited core changes have landed for the next kernel release, but there are likely to be more significant changes to come.

Interesting changes merged so far include:

BPF

  • The ability to create destructive BPF programs has been added. The initial proposal included a panic() function, but what was finally merged was a crash_kexec() kfunc instead. This is a lower-level entry point that does not do all of the cleanup work that panic() tries to handle.
  • There is support in BPF for iterating through control groups. This feature is undocumented; some information can be found in this commit.
  • The BPF-specific memory allocator has been merged.
  • There is a new "user ring buffer" BPF map type for fast data transfer between a BPF program and user space. Little documentation exists, but this merge message has an overview.
  • BPF task iterators can now iterate through the resources of a single thread; this merge message appears to be the only documentation that exists.

Core kernel

  • Experimental support for the Rust programming language has been pulled into the mainline. Following the decisions made at the recently concluded kernel maintainers summit, this is a minimal version of the patch set, without the drivers that have been implemented in Rust so far. This documentation commit contains more information, and some small sample modules are available as well.
  • Support for the a.out executable format was disabled in the 5.18 release. Nobody has complained, so now that support has been removed entirely from the kernel.

Filesystems and block I/O

  • The erofs filesystem has gained the ability to share duplicated data across filesystems.
  • The statx() system call can now return information on whether a given file can support direct I/O and, if so, what the alignment requirements are. There is a man-page update describing the new API, and some information can be found in this changelog as well.

Hardware support

  • Graphics: MediaTek mt8195 DisplayPort units.
  • Hardware monitoring: Microchip EMC2305 and compatible EMC2301/2/3 fan controllers, Analog Devices MAX31760 fan-speed controllers, and TEXAS tps546d24 buck converters.
  • Miscellaneous: Microchip PCI1XXXX's I2C interfaces, MediaTek MT6331 and MT6332 power-management ICs, Nuvoton NCT6116 GPIO controllers, the AMD platform management framework, MediaTek MT6370 backlight controllers, Broadcom STB memory controllers, and Alibaba T-Head Yitian 710 DDR Sub-system Driveway performance-monitoring units.
  • Networking: Wangxun GbE PCI Express adapters, Microsemi Ocelot controllers, and Analog Devices ADIN1110 MAC-PHYs.
  • Sound: Texas Instruments SRC4XXX DIR/DIT and SRC codecs, Everest Semi ES8326 codecs, NXP i.MX8ULP digital signal processors, Apple Silicon MCA audio subsystems, and Intel SkyLake and KabyLake audio processors.
  • Some support patches to enable creating human input device (HID) drivers in BPF have been merged, but the full mechanism looks like it will have to wait another cycle.

Miscellaneous

  • The top-level page for the kernel's Documentation tree has been significantly rewritten to ease the process of finding something useful, especially when using a web browser. The results can be seen now in linux-next, and will show up in the rendered mainline documentation after 6.1-rc1.

Networking

  • Support for the old DECnet protocol has been removed from the kernel. The user-space API definitions remain so that programs with DECnet support will continue to compile, but they will never find a functioning DECnet network.
  • The netlink protocol has finally been documented in the kernel source. The HTML version of this manual is available on kernel.org.
  • The TCP stack can now use a separate, per-namespace hash table for sockets, improving performance on systems with a lot of busy network namespaces. This table is disabled by default; this commit describes how to configure it.

Security-related

  • The LLVM-based control-flow-integrity mechanism for the kernel, which was merged for the 5.13 release, has been replaced with a new implementation that better suits the kernel's needs.
  • There is a new security-module hook to control the ability to create user namespaces; this feature was merged despite strong opposition (which is ongoing) from the namespace maintainer.
  • Support for performing PKCS#7 signature verification in BPF programs has been added. Documentation has evidently been deferred for another development cycle, but this merge message gives an overview of why this feature exists and how it works.

Internal kernel changes

  • The API for thermal-related devicetree initialization has been significantly changed, and drivers have been updated to match. The new API is resolutely undocumented, but some information can be found in this commit.

As of this writing, there are numerous major repositories that are yet to be pulled into the mainline, so there are almost certainly some big changes waiting in the wings. Tune back in after the close of the merge window (almost certainly on October 16) for a summary of the changes pulled in the second half.

Index entries for this article
KernelReleases/6.1


(Log in to post comments)

The first half of the 6.1 merge window

Posted Oct 7, 2022 19:10 UTC (Fri) by bartoc (subscriber, #124262) [Link]

What's this about "YAML based parsing" for netlink. I'm assuming that does not mean like, actual YAML the format.

The first half of the 6.1 merge window

Posted Oct 7, 2022 19:32 UTC (Fri) by Tobu (subscriber, #24111) [Link]

Found this: https://lore.kernel.org/netdev/20220811022304.583300-1-kuba@kernel.org/T/

YAML-based specs describe netlink interfaces so that userspace bindings don't have to be derived from uapi headers and C knowledge. This seems similar to gobject-introspection or other machine-readable API (and ABI) descriptions.

The first half of the 6.1 merge window

Posted Oct 7, 2022 23:14 UTC (Fri) by flussence (subscriber, #85566) [Link]

And the patchset makes direct reference to devicetree YAML, which seems like a fairly solid thing to base this off of.

IIRC a lot of the graphics stack (X11, Mesa, Wayland) does protocol bindings in a similar way nowadays, but those are XML. It seems like a fairly successful way to do things.

The first half of the 6.1 merge window

Posted Oct 8, 2022 1:43 UTC (Sat) by kees (subscriber, #27264) [Link]

Note that CFI is now available for x86_64. Before now it was arm64 only.

The first half of the 6.1 merge window

Posted Oct 8, 2022 7:48 UTC (Sat) by Lionel_Debroux (subscriber, #30014) [Link]

Besides less narrow ISA support, now on to at least backward-edge CFI ? After all, an existing, production-grade implementation of CFI for Linux and other programs was published in the open ~7 years ago, as we both know :)

The first half of the 6.1 merge window

Posted Oct 8, 2022 2:53 UTC (Sat) by developer122 (guest, #152928) [Link]

> There is a new security-module hook to control the ability to create user namespaces; this feature was merged despite strong opposition (which is ongoing) from the namespace maintainer.

This strikes me as being as insane as allowing someone to block the subdivision of capabilities in CHERI. It fundamentally nullifies the purpose of the feature.

The first half of the 6.1 merge window

Posted Oct 8, 2022 15:46 UTC (Sat) by geofft (subscriber, #59789) [Link]

The argument is that a lot of people currently turn off unprivileged user namespace creation _entirely_, for attack surface reduction - which is an understandable thing to do. And doing that certainly nullifies the purpose of the feature. Letting an LSM control it gives these users options to allow user namespace creation sometimes instead of an all-or-nothing choice.

I actually find Linus's argument in https://lwn.net/ml/linux-kernel/CAHk-=wjjKsSmNVLa1e22Q29-... compelling:

> if we have a security hook for "create random file", then the notion that creating a whole new namespace somehow must not have any security hooks because it's *so* special is just ridiculous.'

The first half of the 6.1 merge window

Posted Oct 8, 2022 17:13 UTC (Sat) by jhoblitt (subscriber, #77733) [Link]

I understand the incentive to get features into a release as soon as they are ready. I'm curious as to what the track record has been for the promise of "if you merge this now, I will document it later."?

The first half of the 6.1 merge window

Posted Oct 9, 2022 11:40 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

Separate metrics which at least leave "TODO" breadcrumbs would be appreciated. Though I wonder if there's an FSF-style "TODOs are messy, please don't add them" being "worse" than no mention of anything at all causing a ENODATA problem with that.


Copyright © 2022, 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