|
|
Subscribe / Log in / New account

5.18 Merge window, part 2

By Jonathan Corbet
April 4, 2022
Linus Torvalds released the 5.18-rc1 kernel prepatch on April 3, after having pulled 13,207 non-merge changesets into the mainline repository. This merge window has thus not only been turbulent, with a significant number of regressions and refused pull requests, it has also been relatively busy. Just over 9,000 of those changesets were pulled after the first 5.18 merge window summary was written; the time has come to catch up with the remainder of changes merged for this development cycle.

The most interesting changes pulled in the latter part of the 5.18 merge window include:

Architecture-specific

  • Live patching is now supported for 32-bit PowerPC systems.
  • The RISCV architecture has gained support for the "Sv57" page-table format. This is a five-level format with support for 57-bit virtual addresses.
  • The RISCV perf implementation has been ripped out and replaced with one based on the SBI PMU and Sscofpmf extensions; that allows for support of most perf features.
  • The RISCV SBI CPU-idle extension is supported as of 5.18.
  • RISCV has also gained support for restartable sequences.
  • The Intel software-defined silicon driver, which allows Intel to control which features of a given processor can be used, has been merged.
  • Support for AMD's "host system management port", which is "an interface to provide OS-level software with access to system management functions via a set of mailbox registers", has been merged. A small amount of additional information can be found in this documentation commit.

Core kernel

  • The BPF type format (BTF) mechanism can now annotate variables that refer to user-space memory. Among other things, this gives the verifier a better way to detect and check user-space memory accesses. See this merge changelog for more information.
  • The BPF program-packing memory allocator has been merged; it allows for more efficient memory use in systems with a large number of loaded BPF programs.
  • The MADV_DONTNEED madvise() command now works with hugetlb pages.
  • There is a new madvise() operation, MADV_DONTNEED_LOCKED, which will (like MADV_DONTNEED) cause the reclaim of the indicated pages. Unlike MADV_DONTNEED, though, this operation even applies to pages that have been locked into memory; the pages are forced out, but their "locked" status does not change. So if the affected pages are faulted back in, they will be locked again. This changelog explains the reasoning behind this functionality.

Filesystems and block I/O

  • Device-mapper I/O accounting has been significantly reworked, resulting in much more accurate accounting for targets like dm-crypt.
  • The Reiserfs filesystem has been deprecated with an eye toward removal in 2025.
  • Support for write streams has been removed from the block subsystem. There are currently no devices supporting that functionality and no real prospect of any being added.
  • 64-Bit integrity checksums on NVMe devices are now supported.
  • The exfat filesystem has a new mount option (keep_last_dots) that will cause it to not strip trailing periods from file names; this makes the filesystem incompatible with Windows, which does strip trailing periods.

Hardware support

  • Clock: Microchip PolarFire clock controllers, Renesas RZ/G2L clock controllers, Renesas 9-series PCIe clock generators, NXP i.MX93 clock controllers, StarFive JH7100 audio clocks, Apple M1 numerically controlled oscillators, Qualcomm QCM2290, SM6125, and SM6350 display clock controllers, Qualcomm SM6350 graphics clock controllers, and Allwinner H616/R329 RTC clock controllers.
  • Graphics: ChromeOS privacy-screen controllers, ITE IT6505 DisplayPort bridges, Solomon SSD130x OLED displays, and MIPI DBI-compatible panels.
  • Industrial I/O: Semtech SX9324 and SX9360 proximity sensors, Analog Devices ADXL367 3-axis accelerometers, Analog Devices ADMV1014 microwave downconverters, Analog Devices ADA4250 instrumentation amplifiers, Analog Devices ADMV4420 K-band downconverters, and Analog Devices LTC2688 digital-to-analog converters.
  • Miscellaneous: SiGma Micro-based keyboards, Airoha EN7523 GPIO controllers, uPI uG3105 battery monitors, Injoinic IP5xxx power bank ICs, Macronix external hardware ECC engines, Silergy SY7636A temperature sensors, Maxim Semiconductor MAX77714 power-management ICs, AMD PSP I2C semaphores, MediaTek ADSP mailbox controllers, ASPEED PECI controllers, Layerscape security fuse processors, Sunplus on-chip controllers, Sunplus UARTs, Rockchip NANENG COMBO PHYs, MediaTek keypads, and Imagis IST30xxC touchscreens.
  • Networking: Realtek RTL8367S Ethernet switches, Davicom dm9051 SPI Ethernet controllers, Fungible Ethernet adapters, MediaTek MT7986 wireless MACs, MediaTek MT7921U 802.11ax 2x2:2SS wireless adapters, Lynx 28G SerDes PHYs, and I2C-connected Management Controller Transport Protocol (MCTP) devices implementing the DSP0237 specification.
  • Pin control and GPIO: Broadcom BCM4908 pin controllers, Meson s4 pin controllers, Sunplus SP7021 PinMux and GPIO controllers, Renesas R8A779F0 pin-function controllers, Mediatek MT8186 pin controllers, NXP i.MX93 pin controllers, Nuvoton WPCM450 pin and GPIO controllers, and Qualcomm SC8280xp pin controllers.
  • USB: Richtek RT1719 Sink Only Type-C USB controllers and Qualcomm embedded USB debuggers.

Miscellaneous

  • As usual, the user-space perf tools have seen a long list of improvements; see this merge commit for a summary.

Networking

  • The bridge subsystem now has support for multiple spanning trees; see this merge commit for more information.
  • The process of instrumenting the networking code to expose the reason for packet drops continues.
  • BPF programs attached to network control groups can now use a couple of new helper functions to explicitly set the return value for system calls. This enables the communication of better information about why a given system call was rejected.
  • Packet transmission from BPF programs run with BPF_PROG_RUN is now supported. See this merge commit, this changelog, and this documentation patch for more information.
  • Fragment support has been added to the express data path (XDP) mechanism, allowing the processing of jumbo frames and more. See this commit for more information.
  • The teardown of network namespaces has been significantly accelerated, which is important for some large systems with a lot of network traffic.

Security-related

  • The strict memcpy() bounds checking patches have been merged. This work should help to catch a range of memory-safety problems before they ever make it into a production kernel.
  • The kernel is now compiled with the -Warray-bounds and -Wzero-length-bounds warnings enabled. This is the culmination of a long-term effort to eliminate zero-length arrays and related tricks from the kernel code.
  • indirect branch tracking control-flow integrity has been added for the x86 architecture. This feature prevents indirect branches from being redirected to locations that were not intended as the target of such a branch. Specifically, all indirect branches must land on an ENDBR instruction.

Virtualization and containers

  • The virtio-crypto device has gained support for encryption with RSA. Documentation seems to be nonexistent, but this commit may be comprehensible to somebody.

Internal kernel changes

  • As described in this article, the kernel is now compiled against the C11 language standard rather than C89.
  • The new "fprobe" mechanism allows for quick function-call tracing when the full features of ftrace are not needed; see this documentation commit for more information.
  • The build system now supports two new environment variables, USERCFLAGS and USERLDFLAGS; they can be used to pass additional options to the compiler and linker, respectively.
  • There have been more significant changes to the internal support code for network filesystems; see this merge changelog for an overview.
  • The long-deprecated PCI DMA API has been removed; drivers should be using the regular DMA API instead.

The 5.18 kernel now moves into the stabilization phase, where the bugs that inevitably crept in with all of those new features will (hopefully) be found and fixed. Assuming the normal schedule holds, the final 5.18 release can be expected on May 22 or 29.

Index entries for this article
KernelReleases/5.18


to post comments

5.18 Merge window, part 2

Posted Apr 5, 2022 20:56 UTC (Tue) by Sesse (subscriber, #53779) [Link]

Woot, MST support! Linux had been stuck with the most 1980s spanning-tree support forever…

5.18 Merge window, part 2

Posted Apr 11, 2022 6:26 UTC (Mon) by johannbg (guest, #65743) [Link] (14 responses)

> The Reiserfs filesystem has been deprecated with an eye toward removal in 2025.

What's the point or benefit for not removing the filesystem at the same point in time it has been deprecated o_O

5.18 Merge window, part 2

Posted Apr 11, 2022 8:27 UTC (Mon) by mpr22 (subscriber, #60784) [Link] (1 responses)

Deprecation is "hey we're going to stop supporting this you need a migration strategy".

Removal is "ok we're done it's gone now hope you sorted out your migration don't come crying to us if you wasted the whole migration window on futile pleas for us to change our mind".

5.18 Merge window, part 2

Posted Apr 11, 2022 18:49 UTC (Mon) by johannbg (guest, #65743) [Link]

Well people are like water they always take the shortest route so they wont migrate until they have to and they wont have to until the relevant bits are removed and they are forced to update to a newer kernel that does not support those bits so you might just as well remove the bits at the same time they are considered deprecated.

There should be no need for prolonged death or a deprecation window.

5.18 Merge window, part 2

Posted Apr 11, 2022 16:43 UTC (Mon) by flussence (guest, #85566) [Link] (11 responses)

Reiserfs is the sort of thing you either aren't already using, or are deeply stuck using, and three years seems like a reasonable amount of time to make emergency plans to move off it.

5.18 Merge window, part 2

Posted Apr 11, 2022 18:58 UTC (Mon) by johannbg (guest, #65743) [Link] (10 responses)

Well I would think that if an deprecation period truly is necessary it should never be longer than a single upstream longterm maintenance kernel release cycle meanwhile stable could immediately drop it. It should be safe to assume that anyone that is stuck on anything in the kernel is running an enterprise distro with paid support and that paid support arguably should be dealing with issues just like this and if demands are for it continue support it downstream, if not what else are those enterprise distro's good for?

5.18 Merge window, part 2

Posted Apr 12, 2022 16:35 UTC (Tue) by nix (subscriber, #2304) [Link] (9 responses)

> meanwhile stable could immediately drop it.

What a brilliant idea. Now anyone updating to new stable kernels has to consider the possibility that their filesystems suddenly don't work any more and all their data is inaccessible! What could possibly go wrong?

(Seriously, you appear to be operating under the assumption that user data in old filesystems is utterly unimportant and can just be cavalierly deleted. The opposite is true: it's probably both crucial, very hard to move, and largely disregarded, so a long deprecation period with loud warnings is essential.)

5.18 Merge window, part 2

Posted Apr 12, 2022 19:14 UTC (Tue) by johannbg (guest, #65743) [Link] (8 responses)

No I'm operating under the assumption that no downstream users is still using Reiserfs which it's development ceased years ago and if they are they must be on an distribution which has a long term support ( either paid or free ) or are using long term supported kernel which gives them enough time to make the necessary preparement for this change thus are unaffected by this change and the kernel community can immediately drop it as opposed to the kernel community giving mixed signals by continuing to ship it just like they have been doing for years while it's development had ceased.

5.18 Merge window, part 2

Posted Apr 13, 2022 18:32 UTC (Wed) by dullfire (guest, #111432) [Link] (2 responses)

> which it's development ceased years ago

Yeah, nobody uses fat32 either.

5.18 Merge window, part 2

Posted Apr 18, 2022 21:53 UTC (Mon) by flussence (guest, #85566) [Link] (1 responses)

Tangentially related to this whole thread: I recently discovered they've been removing NFSv2 support from the kernel and userspace.

Said discovery came as an unpleasant surprise whereby my NAS (running only NFSv4 for years) failed to reboot properly and broke half my network, because suddenly "--no-nfs-version 2" on rpc.nfsd had gone from working to being a fatal syntax error. Adding to the fun, it's still present and necessary on other tools...

5.18 Merge window, part 2

Posted Apr 19, 2022 13:20 UTC (Tue) by nix (subscriber, #2304) [Link]

Ditto. libnfs 4 and 5 also broke, for reasons I don't entirely understand given that it was using NFSv3 all along. (It ends up dereferencing null pointers and crashing. I switched to ordinary server-side client mounts. The problem went away in 5.16.19, it seems.)

5.18 Merge window, part 2

Posted Apr 14, 2022 8:27 UTC (Thu) by dtardon (subscriber, #53317) [Link] (4 responses)

> No I'm operating under the assumption that no downstream users is still using Reiserfs which it's development ceased years ago

IOW, your assumption is based on the assumption that users have good knowledge of filesystems and would actively move away from old ones. I can assure you that far from the reality.

> and if they are they must be on an distribution which has a long term support ( either paid or free ) or are using long term supported kernel

And what is the basis of this assertion, if I may ask?

5.18 Merge window, part 2

Posted Apr 14, 2022 9:10 UTC (Thu) by johannbg (guest, #65743) [Link] (3 responses)

> I can assure you that far from the reality.

I'm ready to be assured so assure me.

> And what is the basis of this assertion, if I may ask?

The reality you yourself are claiming that I'm so affar from...

5.18 Merge window, part 2

Posted Apr 19, 2022 13:21 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

So... let me get this clear. Because *you* are not using reiserfs, or are using it only on LTS-supported kernels, therefore *everyone* must be? No other possibility exists?

5.18 Merge window, part 2

Posted Apr 19, 2022 18:51 UTC (Tue) by johannbg (guest, #65743) [Link] (1 responses)

I dont see how you reached that conclusion

5.18 Merge window, part 2

Posted Apr 20, 2022 20:47 UTC (Wed) by nix (subscriber, #2304) [Link]

I'm assuming that your assumptions stated above are derived from your own experience. The alternative (that they're just guesses) is even worse...


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