|
|
Subscribe / Log in / New account

5.19 Merge window, part 2

By Jonathan Corbet
June 6, 2022
The 5.19 merge window was closed with the 5.19-rc1 release on June 5 after the addition of 13,124 non-merge changesets to the mainline kernel. That makes this merge window another busy one, essentially matching the 13,204 changesets seen for 5.18. The approximately 8,500 changesets merged since our first 5.19 merge-window summary contain quite a bit of new functionality; read on for a summary of the most interesting changes that were pulled during the second half of this merge window.

Architecture-specific

  • The remaining 32-bit Armv4T and Armv5 systems have finally been dragged into the multi-platform world. As Arnd Bergmann noted in the merge message: "This series has been 12 years in the making, it mostly finishes the work that was started with the founding of Linaro to clean up platform support in the kernel".
  • The h8300 architecture has been removed — again. As noted in the merge message, it was deleted once in 2013 and reinstated two years later. Since then, it has seen almost no maintenance, so now it is gone again.
  • Changes to the riscv architecture include the addition of support for "supervisor-mode page-based memory types" (allowing pages to be marked with attributes like "non-cacheable"), support for running 32-bit binaries on 64-bit systems, and an implementation of kexec_file_load().
  • The initial support for Loongson's "LoongArch" CPU architecture has been merged.

    LoongArch is a new RISC ISA, which is a bit like MIPS or RISC-V. LoongArch includes a reduced 32-bit version (LA32R), a standard 32-bit version (LA32S) and a 64-bit version (LA64).

    This documentation commit has more information about this architecture.

  • There is a new generic ticket spinlock type that can be implemented on most architectures that cannot support a full qspinlock implementation. It is being used by openrisc, csky, and riscv.

Core kernel

  • A new proactive reclaim mechanism has been merged that gives user space some control over working-set management. The memory controller has a new control file called memory.reclaim; writing a number there will initiate an attempt to reclaim that many bytes from the indicated control group. See this commit for more information.
  • The longstanding problems with copy-on-write and get_user_pages() have gotten a bit better with the merging of an extensive set of fixes; this article describes the changes.
  • The kernel can better account for (and control) the use of memory when compressed swapping with zswap is in use; see this changelog for a bit more information.
  • The kernel can now keep track of which modules (if any) tainted the kernel, even after those modules are unloaded.
  • The sysctl knobs for the System V interprocess communication mechanisms have been reworked to be properly associated with each IPC namespace. This paves the way toward allowing unprivileged processes to change them within user namespaces, but that last step has not yet been taken.

Filesystems and block I/O

  • The fanotify mechanism implements a new flag (FAN_MARK_EVICTABLE) that does not pin the targeted inode in the inode cache. If the inode is evicted for any reason, the associated mark will be lost. The purpose of this feature appears to be to allow applications to mark subtrees to be ignored without actually pinning parts of those subtrees in the cache.
  • The XFS filesystem has gained the ability to store billions of extended attributes with any given inode. Evidently, there are people out there who actually want to be able to do that. While they were in the neighborhood, the XFS developers raised the maximum number of extents per file from a measly 4 billion to 247.
  • XFS has also gained a feature called "logged attribute replay"; it allows multiple extended attributes in a file to be modified together in an atomic fashion. This merge message has a bit more information about both changes.
  • The NFS "courteous server" feature will avoid purging lock state for an unresponsive client for up to a day — unless some other client requests a contending lock. Without this feature, an unresponsive client's locks will be unconditionally purged after 90 seconds.
  • The overlayfs filesystem can now handle ID-mapped mounts.

Hardware support

  • Clock: Airoha EN7523 SoC system clocks, Renesas RZ/G2UL clock controllers, R-Car V4H clocks, MediaTek MT8186 clock controllers, STMicroelectronics STM32MP13 reset clock controllers, Qualcomm SC7280 LPASS core & audio clock controllers, Qualcomm SC8280XP global clock controllers, Renesas RZ/N1 realtime clocks, and HPE GXP timers.
  • GPIO and pin control: Marvell 98DX25xx and 98DX35xx pin controllers, Qualcomm SC7280 LPASS LPI pin controllers, Renesas RZ/G2UL pin controllers, and Mediatek MT6795 pin controllers.
  • Graphics: NewVision NV3052C RGB/SPI panels, Lontium LT9211 DSI/LVDS/DPI bridges, Synopsys Designware GP audio interfaces, Intel MEI graphics system controllers, Freescale i.MX8MP LDB bridges, and Rockchip VOP2 visual output processors.
  • Input: Azoteq IQS7222A/B/C capacitive touch controllers and Raspberry Pi Sense HAT joysticks.
  • Miscellaneous: Apple SART DMA address filters, Apple ANS2 NVM Express host controllers, Microchip PolarFire random number generators, NVIDIA Tegra GPC DMA controllers, Renesas RZ/N1 DMA routers, Qualcomm light-pulse generators, Xilinx LogiCORE IP AXI timers, Sunplus pulse-width modulators, Apple eFuses, and Qualcomm SC8280XP and SDX65 interconnect buses.
  • Sound: Generic serial MIDI devices, Realtek ALC5682I-VS codecs, NVIDIA Tegra186 asynchronous sample rate converters, Cirrus Logic CS35L45 smart speaker amplifiers, Mediatek MT8186 audio DSPs, and Analog Devices MAX98396 speaker amplifiers.
  • USB: ON Semi FSA4480 analog audio switches.
  • Watchdog: Sunplus watchdogs, Renesas RZ/N1 watchdogs, and HPE GXP watchdogs.
  • Also: the new "hardware timestamp engine" subsystem supports devices that can record timestamps in response to events. The NVIDIA Tegra 194 timestamp provider is the first device supported by this subsystem.

Miscellaneous

  • The kernel's firmware loader can now handle firmware files that have been compressed with Zstandard. The firmware loader also has a new sysfs file that allows firmware loads to be initiated from user space; there is a bit of documentation in this commit.

Virtualization and containers

  • The virtio-blk driver now supports polled I/O, an enhancement that, according to this commit message, improves latency by about 10%.

Internal kernel changes

All of those changes inevitably brought a lot of bugs with them; the time has now come to try to identify and fix those problems. Assuming that 5.19 turns out to be a normal nine or ten-week cycle (and it has been a long time since anything else has happened), the final 5.19 kernel release will happen on July 24 or 31.

Index entries for this article
KernelReleases/5.19


to post comments

5.19 Merge window, part 2

Posted Jun 8, 2022 2:52 UTC (Wed) by dgc (subscriber, #6611) [Link] (1 responses)

> The XFS filesystem has gained the ability to store billions of extended attributes with any given inode. Evidently, there are people out there who actually want to be able to do that.

I guess it wasn't that obvious; the "people out there who actually want to be able to do this" are the XFS developers themselves. We need somewhere to host reverse directory lookup information (a.k.a. parent pointers) for online verification and repair purposes, to store merkle tree verification data for fsverity, etc. Why bother inventing new mechanisms to store all these new objects when you've already got a generic key-value store built into every inode that scales out to hundreds of millions of individual objects?

-Dave.

5.19 Merge window, part 2

Posted Jun 8, 2022 9:38 UTC (Wed) by a3f (subscriber, #106306) [Link]

> Also: the new "hardware timestamp engine" subsystem supports devices that can record timestamps in response to events. The NVIDIA Tegra 194 timestamp provider is the first device supported by this subsystem.

AFAIK, the counter framework can report events along with a timestamp. Why create a new framework instead of adapting the existing one?


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