|
|
Subscribe / Log in / New account

5.1 Merge window part 2

By Jonathan Corbet
March 17, 2019
By the time that 5.1-rc1 was released and the 5.1 merge window ended, 11,241 non-merge changesets had been pulled into the mainline repository. Of those, just over 5,000 were pulled since the first 5.1 merge-window summary. It often happens that the biggest changes are pulled early, with the emphasis shifting to fixes by the end of the merge window; this time, though, some of the most significant features were saved for last.

Some of the noteworthy changes pulled in the second half of the 5.1 merge window are:

Core kernel

  • The live patching mechanism has a new "atomic replace" feature; it allows a single cumulative patch to replace a whole set of predecessor patches. It is useful in cases where an older patch needs to be reverted or superseded; one use case is described in this article. Some more information can be found in this commit.
  • The io_uring API has been added, providing a new (and hopefully better) way of doing high-performance asynchronous I/O.
  • If the CONFIG_PRINTK_CALLER configuration option is set, messages printed by the kernel will include a new field identifying the thread or CPU ID of the code doing the printing. It is primarily meant to ease the task of reuniting streams of messages that may be interrupted by messages printed elsewhere in the system.
  • It is now possible to use nonvolatile memory as if it were ordinary RAM. This work is described in this article from January; see also this changelog for more information and some important caveats.
  • Opening a process's /proc directory now yields a file descriptor that can be used to refer to the process going forward; as described in this article, the primary purpose is to prevent the delivery of signals to the wrong process should the target exit and be replaced (at the same ID) by an unrelated process. The new pidfd_send_signal() system call (described in this commit) can be used with these file descriptors.

Filesystems and block layer

  • The "exofs" filesystem, meant to run on top of object storage devices, has been removed, along with SCSI-protocol support for those devices in general.
  • The new dm-mod.create= command-line parameter can be used to create device-mapper volumes at boot time without the need for an initramfs. See Documentation/device-mapper/dm-init.txt for more information.
  • The F2FS filesystem has a new mode bit (F2FS_NOCOW_FL) that disables copy-on-write behavior for the affected file.

Hardware support

  • Clock: ZXW Crystal SD3078 realtime clocks, Cadence realtime clocks, Amlogic Meson realtime clocks, MicroCrystal RV-3028 realtime clocks, Abracon AB-RTCMC-32.768kHz-EOZ9 I2C realtime clocks, Epson rx8571 realtime clocks, NXP i.MX8MM CCM clock controllers, and Actions Semi OWL S500 clocks.
  • GPIO and pin control: TQ-Systems QTMX86 GPIO controllers, Gateworks PLD GPIO expanders, AMD Fusion Controller Hub GPIO controllers, and NXP IMX8QM and IMX8MM pin controllers.
  • Graphics: Toppoly TPG110 panels, ARM Komeda display processors, Sitronix ST7701 panels, and Kingdisplay kd097d04 panels. It's also worth noting that the Nouveau driver now has support for heterogeneous memory management, allowing better sharing of RAM between the CPU and the GPU.
  • Input: Maltron L90 keyboards, ViewSonic/Signotec PD1011 signature pads, Sitronix ST1633 touchscreen controllers, and Qualcomm MSM vibrators.
  • Media: Melexis MLX90640 thermal cameras, Omnivision ov8856 sensors, and NXP i.MX7 camera sensor interfaces.
  • Miscellaneous: STMicroelectronics STMPE analog-to-digital converters, STMicroelectronics STPMIC1 power-management ICs, Toshiba Mobile TC6393XB I/O controllers, Mellanox hardware watchdog timers, ChromeOS Wilco embedded controllers, Xilinx ZynqMP IPI mailboxes, and NXP Layerscape qDMA engines.

Security

  • The goal of stacking security modules has been discussed since 2004 (and probably before). This work is finally coming to a conclusion, and many of the necessary low-level changes have been merged for 5.1. There is a new lsm= command-line parameter that controls which modules are loaded, and in which order.
  • The new "SafeSetID" security module has been added; it places limits on user and group ID transitions. For any given user (or group) ID, a change (via executing a setuid program, for example) would only be allowed if this module agrees. ChromeOS is currently using it to implement its security policies; see Documentation/admin-guide/LSM/SafeSetID.rst for more information.
  • The audit subsystem has gained support for namespaced file capabilities.
  • The structleak GCC plugin has been extended to initialize all variables passed by reference on the stack. See this commit for details.

Internal kernel changes

  • The work to convert all fault() handlers to return the special vm_fault_t type has been completed, so now that type has been changed to be incompatible with the previous int type. That will cause compilation failures on any out-of-tree modules that have not been updated.
  • A new "generic radix tree" data structure has been added for simple uses. There is no separate documentation for it, but this commit contains kerneldoc comments describing how it works.
  • The flexible array data structure has been removed; its (few) users have been converted to use generic radix trees instead.
  • The ever-larger file_operations structure has gained a new iopoll() method; it is used by the io_uring mechanism.
  • The handling of masks in the DMA-mapping layer has changed somewhat. Previous kernels required drivers to find a mask that the kernel was willing to accept; now, the mask provided by drivers describes only the device's capabilities, and the kernel worries about higher-level limitations. That should allow the simplification of a lot of driver initialization code. This commit describes the change.
  • The internal handling of filesystem mounts has changed considerably in preparation for the addition of the new mount API. The new system calls have still not been added, though, and seem likely to wait for another development cycle. See this documentation commit for a description of the new internal API.
  • The GCC compiler can use indirect jumps for switch statements; those can end up using retpolines on x86 systems. The resulting slowdown is evidently inspiring some developers to recode switch statements as long if-then-else sequences. In 5.1, the compiler's case-values-threshold will be raised to 20 for builds using retpolines — meaning that GCC will not create indirect jumps for statements with less than 20 branches — addressing the performance issue without the need for code changes that might well slow things down on non-retpoline systems.

Unless something perturbs the usual schedule, the final 5.1 release can be expected at the beginning of May.

Index entries for this article
KernelReleases/5.1


to post comments


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