|
|
Subscribe / Log in / New account

The rest of the 6.6 merge window

By Jonathan Corbet
September 11, 2023
Linus Torvalds released 6.6-rc1 and closed the 6.6 merge window on September 10. At that point, 12,230 non-merge changesets had been pulled into the mainline repository, which is exactly 500 more than were pulled for 6.5 at this stage in the cycle. Over 7,000 of those changes were pulled after our first-half summary was written; they brought a fair amount of new functionality with them. Read on for an overview of those changes.

Significant changes pulled in the second half of this merge window include:

Architecture-specific

  • After years of work and discussions, the Intel shadow-stack patches have finally been merged. This hardware feature hardens user-space code against stack-overwrite attacks.
  • The PowerPC architecture now supports "hotplug SMT", where some or all of the simultaneous multithreading CPUs in a given core can be enabled or disabled at run time.
  • Changes merged for RISC-V include support for user-space access to performance counters, the ability to locate crash kernels above the 4GB boundary, support for LLVM-implemented forward-edge control-flow integrity, and support for kernel address-space layout randomization.
  • The s390 architecture has removed the noexec command-line parameter, on the reasoning that there is no point in being able to disable non-executable mappings. This change mirrors a similar removal for x86 in 5.19.
  • The LoongArch architecture has gained support for a number of kernel-development tools, including KDB, KGDB, kcov, KFENCE, and KASAN.

Core kernel

  • The new "eventfs" subsystem significantly improves the memory efficiency of the tracing subsystem. There are thousands of tracepoints in the kernel, each of which requires inodes and dentries for its representation in the filesystem. Those structures exist even if tracing is not used, wasting memory. Eventfs will allocated the needed structures only when they are needed, eliminating that waste.
  • The /proc/pid/smaps file now includes information on how well kernel samepage merging (KSM) is working to reduce memory usage.

Filesystems and block I/O

  • The overlayfs filesystem has gained the ability to use fs-verity data to ensure the integrity of data supplied by lower-level filesystems; this is part of a larger effort to get overlayfs to provide the features needed by the composefs filesystem.
  • The reiserfs filesystem has been marked as being obsolete, a step toward its eventual removal.
  • The process of merging the online repair functionality for XFS has begun, though it may be a while yet before this code is all upstream and ready for use.
  • The NFS server now supports NFSv4 write delegations. This mechanism allows for more caching of data and metadata for a file being written to, reducing network traffic and increasing performance.
  • The Ceph filesystem has gained fscrypt support.
  • The ksmbd server (providing in-kernel SMB3 filesystem support) is no longer considered "experimental".

Hardware support

  • Clock: StarFive JH7110 clocks, Renesas VersaClock 3 clock controllers, and Qualcomm IPQ5018 global clock controllers.
  • GPIO and pin control: Amlogic C3 SoC pin controllers, Qualcomm SM6115 and SM8350 LPASS LPI pin controllers, and Intel Tangier pin controllers.
  • Graphics: Visionox R66451 panels and Loongson display controllers.
  • Industrial I/O: Allwinner D1/T113s/T507/R329 analog-to-digital converters, Murata IRS-D200 PIR sensors, and Microchip MCP4728 digital-to-analog converters.
  • Input: Azoteq IQS7222D touch controllers and Azoteq IQS7210A/7211A/E trackpad/touchscreen controllers.
  • Media: Generic I2C address translators, TI DS90UB960 FPD-Link III deserializers, TI DS90UB913 and DS90UB953 FPD-Link III serializers, Dongwoo DW9719 lens voice coils, and Intel visual sensing controllers.
  • Miscellaneous: Huawei HCCS interconnect controllers, Loongson-2 SoC power management controllers, Schweitzer Engineering Laboratories SEL-3350 LED controllers, Siemens Simatic CMOS batteries, Nuvoton NPCM PECI controllers, IBM I2C responders, NXP QorIQ eFuses, Qualcomm secure QFPROMs, Google Stadia force-feedback controllers, Starfive JH7110 PCIE 2.0 PHYs, StarFive JH7110 D-PHYs, Qualcomm M31 HS PHYs, Maxim MAX735x/MAX736x I2C mux/switches, NXP PCA995x I2C-controlled LEDs, Siemens Simatic IPC BX-21A LEDs and Marvell GTI watchdog timers.
  • Sound: TI TAS2781 codecs, Cirrus Logic CS35L56 amplifiers, Realtek RT1017 SDCA codecs, Awinic aw88261 amplifiers, Intel Lunarlake audio interfaces, AMD ACP5x audio interfaces, and Cirrus Logic CS42L43 codecs. Also: the sound layer can now manage devices provided by the industrial I/O subsystem as audio devices.
  • USB: Realtek RTD USB2 and USB3 PHY transceivers, USB MIDI 2.0 gadget interfaces, and Starfive JH7110 USB 2.0 PHYs.

Miscellaneous

  • The tools/workqueue directory includes a new tool, wq_dump.py, that can be used to examine the current configuration of the system's workqueues and how they map onto worker pools. See this commit for some more information.
  • Another set of enhancements to the perf tool has been merged; see this commit for details.

Security-related

  • The NFS server no longer supports the (long-deprecated) DES and triple-DES Kerberos encryption types.

Virtualization and containers

Internal kernel changes

  • Unbound workqueues have gained a number of options aimed at improving performance on larger systems; see the latter part of this article and the "affinity scopes" section of Documentation/core-api/workqueue.rst for the details.
  • Kernel builds with W=1 set now enable the -Wformat-overflow, -Wformat-truncation, -Wstringop-overflow, and -Wrestrict warnings. The -Wenum-conversion warning is now enabled unconditionally.
  • There was an increase of 326 exported symbols during this merge window; see this page for the full list of changes. One kfunc (bpf_map_sum_elem_count()) was added as well.
  • The support files for the GitLab continuous-integration tests used by the graphics subsystem have been merged. See Documentation/gpu/automated_testing.rst for more information on how this testing works.

One significant change that was not merged was, once again, the bcachefs filesystem. Curious readers can see the associated discussion; in short, Torvalds was not happy that the code had never appeared in linux-next (a situation that is being rectified) and had some problems that wider testing should have found. Even Torvalds, though, said that "any further changes are better done in-tree"; it should be possible to get this code into 6.7.

Meanwhile, the time has come to fix as many bugs as possible and to get this code into shape for the 6.6 release. Assuming the usual schedule holds (and it always does anymore), that release can be expected on October 29 or November 5. While it is possible that the next release, 6.7, could happen on December 31, that seems unlikely, meaning that 6.6 is almost certainly the final kernel release for 2023. Should that prove to be the case, it will probably be the long-term-support release for this year as well.

Index entries for this article
KernelReleases/6.6


to post comments

The rest of the 6.6 merge window

Posted Sep 11, 2023 18:01 UTC (Mon) by flussence (guest, #85566) [Link]

ksmbd went from experimental to stable an order of magnitude sooner than some NFS4 features…

I've played around with it and it works, but for the life of me I couldn't figure out how to get it to transmit regular Unix permissions though; a bit of a deal breaker if I want to replace NFS. Which I do, given all the headaches that's given me.

The rest of the 6.6 merge window

Posted Sep 11, 2023 18:08 UTC (Mon) by Sesse (subscriber, #53779) [Link] (3 responses)

It's interesting that online XFS repair is starting to get merged without having online XFS fsck (aka scrub) being marked as stable first. For large filesystems, it's very nice to be able to do regular checking instead of the dreaded 180-day monster fscks on a reboot (or, of course, going un-fscked, which has its own risks).

The rest of the 6.6 merge window

Posted Sep 12, 2023 12:14 UTC (Tue) by hmh (subscriber, #3838) [Link] (2 responses)

Unless you special-cased something, XFS doesn't fsck AFAIK: fsck.xfs does nothing.

Did you (or your distro) add something on boot that calls xfs_repair (instead of fsck.xfs) when it has been longer than 180 days since the last time it was verified?

Also, for XFS, wouldn't online repair end up being the same as online fsck?

The rest of the 6.6 merge window

Posted Sep 12, 2023 12:17 UTC (Tue) by Sesse (subscriber, #53779) [Link] (1 responses)

> Unless you special-cased something, XFS doesn't fsck AFAIK: fsck.xfs does nothing.

I'm talking about the 180-day fsck.ext4 rule.

> Also, for XFS, wouldn't online repair end up being the same as online fsck?

No? There's a huge difference between checking for errors and trying to fix them online.

The rest of the 6.6 merge window

Posted Sep 14, 2023 20:35 UTC (Thu) by kamil (subscriber, #3802) [Link]

> I'm talking about the 180-day fsck.ext4 rule.

Hasn't that been off by default for... well, I don't even remember how long now... probably more than a decade?

The rest of the 6.6 merge window

Posted Sep 11, 2023 22:59 UTC (Mon) by osandov (subscriber, #97963) [Link] (2 responses)

> The tools/workqueue directory includes a new tool, wq_dump.py

Cool, another drgn script in the kernel tree :)

The rest of the 6.6 merge window

Posted Sep 12, 2023 4:30 UTC (Tue) by Paf (subscriber, #91811) [Link]

I was going to ask for more about Dragon, but now I see the name. :)

Well, congratulations. I'll have to look in to it for my work - GDB/Crash is a great tool but aggressively clunky and scripting in it is (frankly) some bizarre half broken joke. The work required to get Python support working is wild. It's hard enough to use that I work fairly hard to look for options other than working with a crash dump.

The rest of the 6.6 merge window

Posted Sep 13, 2023 15:13 UTC (Wed) by tesarik (subscriber, #52705) [Link]

My sincere congratulations, Omar!

The rest of the 6.6 merge window

Posted Sep 18, 2023 2:04 UTC (Mon) by mpee (subscriber, #37530) [Link]

PowerPC has supported enabling/disabling SMT threads at runtime more or less forever, by hot(un)plugging the SMT threads using the sysfs CPU hotplug API.

What's new is it can now be controlled through the /sys/devices/system/cpu/smt/control API, which is simpler to use, and is also common with x86.


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