|
|
Subscribe / Log in / New account

5.7 Merge window part 1

By Jonathan Corbet
April 3, 2020
As of this writing, 7,233 non-merge changesets have been pulled into the mainline repository for the 5.7 kernel development cycle — over the course of about three days. If current world conditions are slowing down kernel development, it would seem that the results are not yet apparent at this level. As usual, these changesets bring no end of fixes, improvements, and new features; read on for a summary of what the first part of the 5.7 merge window has brought in.

Architecture-specific

  • A version of the controversial split-lock detection patch has finally been merged. See this changelog for details about how this mode works. At the moment, this work breaks some VMware-based virtual machines, but that will presumably be fixed long before 5.7 is released.
  • The Arm architecture now supports hot-removal of memory.
  • Pointer authentication is now supported for kernel code (along with user space, which has been supported for some time). This work includes return-address signing in the kernel.

Core kernel

  • The io_uring subsystem now includes support for splice() and for automatic buffer selection.
  • The thermal pressure patch set has been merged; it allows the scheduler to take a processor's thermal situation into account when placing tasks.
  • The CPU scheduler's load tracking has finally gained frequency invariance — meaning that it has access to correct utilization values regardless of the CPU's current operating frequency — on the x86 architecture.
  • After a fair amount of back-and-forth, BPF and the realtime preemption patches can now coexist nicely.
  • The new BPF_MODIFY_RETURN BPF program type can be attached to a function in the kernel and modify its return value.

Filesystems and block I/O

  • The Btrfs filesystem provides a new ioctl() command (BTRFS_IOC_SNAP_DESTROY_V2) that allows the deletion of a subvolume by its ID.
  • As expected, the exFAT filesystem module has been deleted to make room for a better one that will be merged into the main kernel via a filesystem tree. This module was not deleted, though, before various developers had made a number of improvements to it that have now been discarded.

Hardware support

  • Graphics: BOE TV101WUM and AUO KD101N80 45NA 1200x1920 panels, Feixin K101 IM2BA02 panels, Parade PS8640 MIPI DSI to eDP converters, TI Keystone display subsystems, Samsung AMS452EF01 panels, Ilitek ILI9486 display panels, Toshiba TC358768 MIPI DSI bridges, TI TPD12S015 HDMI level shifters, Novatek NT35510 RGB panels, and Elida KD35T133 panels.
  • Industrial I/O: Sharp GP2AP002 proximity/ambient-light sensors, Dyna Image AL3010 ambient-light sensors, Analog Devices HMC425A GPIO gain amplifiers, Analog Devices AD5770R digital-to-analog converters, and InvenSense ICP-101xx pressure and temperature sensors.
  • Media: Sony IMX219 sensors and Allwinner DE2 rotation units.
  • Miscellaneous: Analog Devices fan controllers, Qualcomm Atheros AR934X/QCA95XX SPI controllers, MediaTek SPI NOR controllers, Monolithic MP5416 power-management ICs, Monolithic MP8869 regulators, Ingenic JZ SoC operating-system timers, IDT 82P33xxx PTP clocks, Xilinx ZynqMP AES crypto accelerators, and Allwinner sun6i/sun8i/sun9i/sun50i message boxes.
  • Networking: Qualcomm IP accelerators, Synopsys DesignWare XPCS controllers, Marvell USB to MDIO adapters, and TI K3 AM654x/J721E CPSW Ethernet adapters.
  • USB: Intel PMC multiplexers, Ingenic JZ4770 transceivers, Maxim MAX3420 USB-over-SPI controllers, Qualcomm 28nm high-speed PHYs, and Qualcomm USB super-speed PHYs [don't ask us whether "high-speed" is higher-speed than "super-speed" or not...]. The USB subsystem also has a new "raw gadget" interface that allows the emulation of USB devices from user space.
  • Staging notes: the wireless USB subsystem and "ultra wideband" module have been deleted; they have not worked for some time and nobody is working on the code. The HP100 Ethernet driver is also gone from staging. Meanwhile, the Cavium octeon USB controller and wireless interface drivers, which were deleted in 5.6, have been reinstated for 5.7.

Networking

  • The networking layer can now take advantage of hardware that offloads 802.11 encapsulation tasks.
  • The new "Bareudp" module provides generic, level-3 UDP encapsulation that can be used by a number of other tunneling protocols. See the documentation in this commit for more information.
  • Moving a device from one network namespace to another will now adjust the ownership and permissions of the relevant sysfs files accordingly.
  • The work of merging the multipath TCP patches continues, but a fully functional MPTCP implementation in the mainline is still probably a few releases away.

Security-related

  • The SELinux checkreqprot tunable, if set to 1, changes the way that memory protections are checked in security policies; that can have the effect of allowing memory to be made executable regardless of what the loaded policy says. This setting will be deprecated in 5.7, with the plan to disable it entirely in a future release; see this commit for more information.
  • The KRSI security module has been merged — via the networking tree. This module allows the attachment of BPF programs to any security hook in the kernel; its form has changed somewhat since LWN looked at it and the "KRSI" name is no longer used, but the core idea remains the same. This commit contains some documentation for this feature.
  • The kernel's Curve25519 elliptic-curve crypto implementation has been replaced with one that has been formally verified.

Internal kernel changes

  • There is now a generic interrupt-injection mechanism that can be used for debugging and fault-testing purposes.
  • The TRIM_UNUSED_KSYMS configuration option causes the removal from the kernel symbol table of all exported symbols that are not used by the kernel as it is actually configured and built. There are cases (Android in particular) where this removal is desired, but there is also a need to continue to export a number of symbols for externally supplied modules, even if they are not used by the Android kernel itself. The new UNUSED_KSYM_WHITELIST option allows the provision of a list of symbols that should be retained even if they are seemingly unused.
  • It is now possible (via the MAGIC_SYSRQ_SERIAL_SEQUENCE configuration option) to specify a string of characters that is required to enable the magic SysRq functionality on a serial port. The purpose is to keep this functionality available while avoiding spurious commands on serial ports that can generate garbage data.
  • The "unified user-space access-intended accelerator framework" implements shared virtual addresses between the CPU and peripheral devices; it is intended to allow accelerators to "access any data structure of the main cpu". It was merged via the crypto tree. See this commit for documentation.
  • The kunit unit-testing framework can now make test results available via debugfs.

The 5.7 merge window is just beginning; it can be expected to run through April 12 if the usual schedule holds. As always, LWN will catch up with the rest of the changes pulled for 5.7 once the merge window closes.

Index entries for this article
KernelReleases/5.7


to post comments

5.7 Merge window part 1

Posted Apr 4, 2020 17:56 UTC (Sat) by meyert (subscriber, #32097) [Link]

5.7 Merge window part 1

Posted Apr 4, 2020 19:56 UTC (Sat) by zx2c4 (subscriber, #82519) [Link] (2 responses)

> The kernel's Curve25519 elliptic-curve crypto implementation has been replaced with one that has been formally verified.

Note that the one being replaced this cycle is the x86_64 implementation. We've had for a while two generic C versions (32-bit and 64-bit) that are also formally verified. That means there are three formally verified 25519 implementations in the kernel now. The arm32 implementation is not formally verified, but it comes from djb's qhasm and I'd be extremely surprised to find an arithmetic bug in it.

5.7 Merge window part 1

Posted Apr 4, 2020 20:26 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

BTW, is there any work on making Wireguard work in multihoming scenarios? Not just roaming, but full multihoming?

5.7 Merge window part 1

Posted Apr 5, 2020 7:35 UTC (Sun) by zx2c4 (subscriber, #82519) [Link]

5.7 Merge window part 1

Posted Apr 9, 2020 19:03 UTC (Thu) by Alan.Stern (subscriber, #12437) [Link] (5 responses)

USB support: "[don't ask us whether "high-speed" is higher-speed than "super-speed" or not...]".

The nomenclature goes like this (from slowest to fastest): low speed (1.5 Mb/s), full speed (12 Mb/s), high speed (480 Mb/s), SuperSpeed (5000 Mb/s), SuperSpeedPlus (10000 Mb/s). Yes, those last two concatenated-and-CamelCased oddballs are the official names.

5.7 Merge window part 1

Posted Apr 10, 2020 0:12 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

I can't wait for "SuperDuperSpeed+" then.

5.7 Merge window part 1

Posted Apr 10, 2020 21:22 UTC (Fri) by mstone_ (subscriber, #66309) [Link] (3 responses)

you say that as though the names aren't stupid?

the industry should just use numbers and give the collective finger to the idiocy that came up with this

5.7 Merge window part 1

Posted Apr 11, 2020 1:09 UTC (Sat) by mathstuf (subscriber, #69389) [Link] (2 responses)

They screwed that up too:

- USB 1.0: 1.5 Mb/s for Low Speed, 12 Mb/s for Full Speed
- USB 2.0: adds 480 Mb/s High Speed
- USB 3.0: 5Gb/s for SuperSpeed
- USB 3.1: 10Gb/s for SuperSpeed+
- USB 3.2: 20Gb/s for SuperSpeed+ (no USB B support here) (yes, the same brand name)
- USB4: 40Gb/s for SuperSpeed+ and TB3 (yes, there is no space after "USB") (only USB C support)

So if you're looking for consistency, USB 2.0 era pretty much was the last place for that in the USB world. USB C may have the same socket everywhere, but now you need to worry about feature set of the port you're connecting to (usually described by decals next to the port, but some folks don't want such things blemishing their designs *cough*Apple*cough*).

5.7 Merge window part 1

Posted Apr 11, 2020 6:34 UTC (Sat) by nybble41 (subscriber, #55106) [Link] (1 responses)

It's worse than that—the new standards incorporate the older standards *using the new version number*, so for example a device can truthfully claim to support "USB 3.2" without actually supporting 20Gb/s data transfers. The full nomenclature goes something like this:

5Gb/s: SuperSpeed USB 5Gb/s, USB 3.2 Gen 1x1, USB 3.2 Gen 1, USB 3.1 Gen 1, or (the original name) USB 3.0

10Gb/s: SuperSpeed USB 10Gb/s, USB 3.2 Gen 2x1, USB 3.2 Gen 2, USB 3.1 Gen 2, or USB 3.1

20Gb/s: SuperSpeed USB 20Gb/s, USB 3.2 Gen 2x2, or USB 3.2

USB4 adds Gen 3x1 and Gen 3x2 (40Gb/s) to the mix. So, basically, if you're mainly interested in the speed (like most people would be) then you're better off ignoring the USB version number altogether and looking for the actual transfer rate. Unfortunately, devices don't always clearly advertise the transfer rate they support. After all, a "USB 3.2" label is technically correct and looks better than "SuperSpeed USB 5Gb/s" even if the connection is indistinguishable from USB 3.0.

5.7 Merge window part 1

Posted Apr 11, 2020 12:58 UTC (Sat) by mstone_ (subscriber, #66309) [Link]

I meant the actual connection rate. I know that they also screwed up the version numbering system.


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