|
|
Subscribe / Log in / New account

5.7 Merge window part 2

By Jonathan Corbet
April 13, 2020
By the end of the 5.7 merge window, 11,998 non-merge changesets had been pulled into the mainline repository for this development cycle. That is 1,218 more than were seen during the 5.6 merge window; it would appear that current world events have not succeeded in slowing down the kernel community — at least, not yet. The latter half of the merge window tends to see more fixes and fewer new features, but there are still a number of interesting things that showed up after the first-half summary was written.

Architecture-specific

  • The ability for 32-bit Arm systems to host KVM guests has been dropped.
  • The s390 "fake NUMA" implementation has been removed; there are evidently no scenarios where it can provide performance benefits for s390 systems.
  • the RISC-V architecture has gained support for CPU hotplugging.

Core kernel

  • The control-group memory controller now implements "recursive memory.low protection". The memory.low value indicates a minimum amount of memory that the members of the group should be able to share but, in current kernels, it is inflexible and must be configured at every level of the control-group hierarchy. If that hierarchy is mounted with the memory_recursiveprot option, though, a memory.low value set in a high-level node automatically applies to all children unless explicitly overridden, allowing more flexible run-time allocation of memory within the hierarchy. See the above-linked changelog for more details on how it works.
  • It is now possible to spawn a process directly into a control group using clone3().
  • The cgroupfs filesystem used to manage control groups now supports extended attributes; the use case appears to be to allow notes to be left for user-space management daemons.
  • The userfaultfd() mechanism now has the ability to write-protect pages in the target process. A small amount of documentation can be found in this commit.

Filesystems and block I/O

  • As expected, there is a new implementation of the exFAT filesystem; this one is provided by Samsung with Microsoft's blessing.
  • The F2FS filesystem now supports compression with zstd.
  • The Ceph filesystem can perform file create and unlink operations locally without waiting for the server to respond, speeding tasks (such as an rsync operation) that do a lot of that kind of work.

Hardware support

  • Clock: MediaTek MT2712 realtime clocks, Qualcomm SM8250 global clock controllers, Qualcomm SC7180 modem clock controllers, Spreadtrum SC9863A clocks, and Ricoh RC5T619 realtime clocks.
  • Miscellaneous: UniPhier XDMAC external DMA controllers, Ingenic JZ4780 EFUSE memory, devices connected via the Modem Host Interface (MHI) bus, Qualcomm SC7180 and OSM L3 interconnect buses, CoreSight cross trigger interfaces, Meson AXG MIPI + PCIE analog PHYs, Freescale Layerscape PCIe Gen4 controllers, Amlogic Meson secure power domains controllers, SGI Octane front-panel LEDs, Azoteq IQS620A/621/622/624/625 multi-function sensors, Ricoh RN5T618/RC5T619 power-management ICs, Spreadtrum thermal sensors, Freescale i.MX8MM temperature sensors, ChromeOS embedded controller type-C connectors, and Texas Instruments K3 RTI watchdogs.
  • Pin control and GPIO: Qualcomm IPQ6018 pin controllers, Dialog Semiconductor DA9062 PMIC pin and GPIO controllers, and Mellanox BlueField 2 SoC GPIO controllers.
  • Sound: Amlogic AIU audio output subsystems, Amlogic T9015 digital-to-analog converters, Texas Instruments TLV320ADCX140 codecs, Realtek RT5682 codecs, Broadcom BCM63XX I2S modules, and Maxim MAX98360A amplifiers.
  • vDPA: the kernel now supports vDPA devices which, according to this commit, have a data path compliant with the virtio specification. These devices can be virtual themselves, but they can also implement virtio in the hardware. Two Intel devices are the first to use this support.

Miscellaneous

  • The GPIO subsystem provides a new ioctl() command that allows a process to be informed when the properties of any GPIO line change. This commit contains an example utility that uses this feature.

Virtualization and containers

  • There is a new free-page reporting mechanism by which a guest can inform the host that specific pages are no longer in use. The host can then respond by reclaiming the pages. Some documentation can be found in this commit and this commit.
  • KVM has been fixed to address the problems introduced by split-lock detection; out-of-tree, VMX-based hypervisors will still have problems.

Internal kernel changes

  • The development of explicit pinning of user-space pages continues in the hope of finally solving a number of longstanding problems with get_user_pages(). In particular, the tracking of pinned pages has been implemented, but the decisions on how such pages should be handled are yet to be made.
  • The dynamic debugging mechanism can now be used in the absence of the debugfs virtual filesystem via a new control file at /proc/dynamic_debug/control.
  • The new vm_insert_pages() is a batched version of vm_insert_page(); it puts multiple pages into a user-space virtual memory area with reduced locking overhead.
  • The minimum version of binutils required to build the kernel has been raised to 2.23.
  • The new LLVM=1 command-line option causes the kernel to be built using LLVM utilities rather than GCC and binutils. To use the integrated assembler, though, LLVM_IAS=1 must also be supplied; the old AS=clang option no longer works for this purpose.
  • The last patches applied before the merge window closed sorted the MAINTAINERS file (back) into alphabetical order, thus probably creating a bountiful supply of merge conflicts going forward. To help ensure that this supply is truly bountiful, the order of the fields within each entry has also been sorted alphabetically.

The time has come to fix the bugs in all that new code and turn 5.7 into a proper release. If the usual schedule holds, that release can be expected on either May 31 or June 7.

Index entries for this article
KernelReleases/5.7


to post comments

5.7 Merge window part 2

Posted Apr 13, 2020 16:40 UTC (Mon) by MattBBaker (subscriber, #28651) [Link] (7 responses)

Interesting about the LLVM options. Does the kernel build correctly with LLVM these days?

5.7 Merge window part 2

Posted Apr 14, 2020 14:16 UTC (Tue) by Paf (subscriber, #91811) [Link]

I'm not sure of the current state, but it's been possible to build some more common/simpler configs with LLVM for a while. I imagine this is just further along in that continuum from "can't build at all" to "same support as GCC" (which may never be fully reached).

5.7 Merge window part 2

Posted Apr 15, 2020 5:39 UTC (Wed) by geofft (subscriber, #59789) [Link]

Yes, at least for certain architectures / options. Google announced that the Pixel 2's kernel is built with clang, for instance.

5.7 Merge window part 2

Posted Apr 15, 2020 13:32 UTC (Wed) by darwi (subscriber, #131202) [Link] (1 responses)

> Interesting about the LLVM options. Does the kernel build correctly with LLVM these days?

I've just tried an x86-64 kernel build, using the LLVM 10 binaries hosted at releases.llvm.org, and got a big lld (the llvm linker) C++ stack dump at the final kernel linking stage :)

5.7 Merge window part 2

Posted Apr 16, 2020 23:41 UTC (Thu) by darwi (subscriber, #131202) [Link]

> I've just tried an x86-64 kernel build, using the LLVM 10 binaries hosted at releases.llvm.org, and got a big lld (the llvm linker) C++ stack dump at the final kernel linking stage :)

This segfault will be fixed in llvm 10.0.1: https://bugs.llvm.org/show_bug.cgi?id=45553

5.7 Merge window part 2

Posted Apr 15, 2020 15:18 UTC (Wed) by jezuch (subscriber, #52988) [Link] (1 responses)

Does anyone know if this also supports LLVM LTO? What's the current state of LTO support with gcc anyway?

5.7 Merge window part 2

Posted Apr 17, 2020 2:33 UTC (Fri) by flussence (guest, #85566) [Link]

I found some mention of kernel LTO patches on the web from the early 4.x era, but I don't see anything more than that; the current tree makes no mention of it at all.

5.7 Merge window part 2

Posted Apr 23, 2020 12:54 UTC (Thu) by Gonsolo (guest, #138409) [Link]

I tried with clang-9 from Ubuntu eoan; it failed. I believe at least version 10 is needed (see other comments). Eventually the required version of LLVM and Clang should probably be mentioned in changes.rst and a check added to the Makefile.

Bad naming

Posted May 1, 2020 16:19 UTC (Fri) by Hi-Angel (guest, #110915) [Link]

> The new vm_insert_pages() is a batched version of vm_insert_page()

Oh, I would have NAKed such naming. These functions differ in just one character, it is easy to confuse one with the other while reading. They should perhaps either rename the first one to `vm_insert_one_page`, or the other one to `vm_insert_many_pages`.

5.7 Merge window part 2

Posted May 20, 2020 13:09 UTC (Wed) by andy_shev (subscriber, #75870) [Link]

> sorted the MAINTAINERS file (back) into alphabetical order
...and checkpatch.pl started complaining about new entries being not ordered correctly.


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