|
|
Subscribe / Log in / New account

What's coming in the next kernel release (part 1)

By Jonathan Corbet
December 31, 2018
When the 4.20 kernel was released on December 23, Linus Torvalds indicated that he would try to keep to the normal merge window schedule despite the presence of the holidays in the middle of it. Thus far, he seems to be trying to live up to that; just over 8,700 changesets have been merged for the next release, which seems likely to be called 5.0. A number of long-awaited features are finally landing in the kernel with this release.

Some of the more significant changes merged so far are:

Architecture-specific

  • Intel's processor trace functionality is now supported for use by virtualized guests running under KVM.
  • The arm64 architecture has gained support for a number of features including the kexec_file_load() system call, 52-bit virtual address support for user space, hotpluggable memory, per-thread stack canaries, and pointer authentication (for user space only at this point). This commit has some documentation for the pointer-authentication feature.

Core kernel

  • The long-awaited energy-aware scheduling patches have finally found their way into the mainline. This code adds a new energy model that allows the scheduler to determine what the relative power cost of scheduling decisions will be. It will enable the mainline scheduler to get better results on mobile devices and, with luck, reduce or eliminate the scheduler patching that various vendors engage in now.
  • 64-Bit versions of the ppoll(), pselect6(), io_pgetevents(), recvmmsg(), futex(), and rt_sigtimedwait() system calls have been added for 32-bit systems, making it possible to use these calls successfully after the year-2038 apocalypse. This completes the set of top-level system call conversions. According to Arnd Bergmann: "Hopefully in the next release we can wire up all 22 of those system calls on all 32-bit architectures, which gives us a baseline version for glibc to start using them".
  • The cpuset controller now works (with reduced features) under the version-2 control-group API. See the documentation updates in this commit for details.

Filesystems and block layer

  • The Btrfs filesystem has regained the ability to host swap files, though with a lot of limitations (no copy-on-write, must be stored on a single device, and no compression allowed, for example).
  • The fanotify() mechanism supports a new FAN_OPEN_EXEC request to receive notifications when a file is opened to be executed.
  • The legacy (non-multiqueue) block layer code has been removed, now that no drivers require it. The legacy I/O schedulers (including CFQ and deadline) have been removed as well.
  • "Binderfs" is a new virtual filesystem used to control the Android binder subsystem. See this commit for some information.

Hardware support

  • Audio: AKM AK4118 S/PDIF transceivers, Amlogic AXG SPDIF inputs, Xilinx I2S audio interfaces, and Cirrus Logic CS47L35/85/90/91 and WM1840 codecs.
  • Graphics: Olimex LCD-OLinuXino bridge panels, Samsung S6D16D0 DSI video mode panels, Truly NT35597 WQXGA dual DSI video mode panels, and Himax HX8357D LCD controllers.
  • I3C: The kernel has a new subsystem for I3C devices, along with drivers for Cadence and Synopsys DesignWare controllers.
  • Industrial I/O: Analog Devices AD7949 and AD7124 analog-to-digital converters, Texas Instruments DAC7311, DAC6311, and DAC5311 digital-to-analog converters, Vishay VCNL4035 light and proximity sensors, PNI RM3100 3-Axis magnetometers, and Microchip MCP41xxx/MCP42xxx digital potentiometers.
  • Media: Sony IMX214 sensors, SECO Boards HDMI CEC interfaces, Allwinner V3s camera sensor interfaces, Rockchip VPU JPEG encoders, Aspeed AST2400 and AST2500 video engines, and Intel ipu3-imgu image processing units.
  • Miscellaneous: Microchip MCP16502 power-management ICs, Macronix MX25F0A SPI controllers, Nuvoton NPCM peripheral SPI controllers, Cavium ThunderX2 SoC uncore PMUs, Alcor Micro AU6601 and AU6621 SD/MMC controllers, TI AM654 SDHCI controllers, Cadence GPIO controllers, Microchip SAMA5D1 PIOBU GPIO controllers, Spreadtrum SC27XX fuel gauges, and Intel Stratix10 SoC FPGA managers.
  • Networking: Aquantia AQtion 5/2.5GbE USB network interfaces, Quantenna QSR1000/QSR2000 wireless network interfaces, and MediaTek GMAC Ethernet controllers.
  • USB: Cadence Sierra USB PHYs and Freescale i.MX8M USB3 PHYs.

Networking

  • Generic receive offload (GRO) can now be enabled on plain UDP sockets. If the numbers in this commit are to be believed, the result is a significant increase in receive bandwidth and a large reduction in the number of system calls required.
  • ICMP error handling for UDP tunnels is now supported.
  • The MSG_ZEROCOPY option is now supported for UDP sockets.

Security

  • Support for the Streebog hash function (also known as GOST R 34.11-2012) has been added to the cryptographic subsystem.
  • A new crypto mode called "Adiantum" has been added as a replacement for the (removed) Speck algorithm. Adiantum is intended to be secure while being fast enough to perform disk encryption on low-end handsets; see this commit message for details. As part of this work, support for the XChaCha12 and XChaCha20 stream ciphers was also added.
  • The kernel is now able to support non-volatile memory arrays with built-in security features; see Documentation/nvdimm/security.txt for details.

Internal kernel changes

  • There is a new "software node" concept that is meant to be analogous to the "firmware nodes" created in ACPI or device-tree descriptions. See this commit for some additional information.
  • The first two of the retpoline-elimination mechanisms described in this article have been merged. improving performance in core parts of the DMA mapping and networking layers.
  • The software-tag-based mode for KASAN has been added for the arm64 architecture.
  • The switch to using JSON schemas for device-tree bindings has begun with the merging of the core infrastructure and the conversion of a number of binding files.
  • The long-deprecated SUBDIRS= build option is finally going away in the 5.3 merge window; users will start seeing a warning as of 5.0. The M= option should be used instead.

Before the 4.20 release, Torvalds had suggested that this merge window would go for longer than usual given the presence of the holidays in the middle. The pace of merging so far suggests that this plan has fallen by the wayside, though, and maintainers should not count on the merge window being open past January 6. As always, LWN will follow up with a summary of the changes that are merged between now and the closing of the merge window, whenever that may be.

Index entries for this article
KernelReleases/5.0


to post comments

What's coming in the next kernel release (part 1)

Posted Dec 31, 2018 19:48 UTC (Mon) by pbonzini (subscriber, #60935) [Link]

Note that processor tracing support in KVM guests is only usable in Ice Lake (iirc, since I don't have the hardware...). Earlier generations do not have the necessary support in the CPU.

What's coming in the next kernel release (part 1)

Posted Dec 31, 2018 23:08 UTC (Mon) by gerdesj (subscriber, #5446) [Link] (2 responses)

Ooh look: linux-4.20.arch1-1-x86_64 has turned up. Don't mind if I do.

What's coming in the next kernel release (part 1)

Posted Dec 31, 2018 23:25 UTC (Mon) by gerdesj (subscriber, #5446) [Link] (1 responses)

$ cat /proc/pressure/cpu
some avg10=0.00 avg60=0.03 avg300=0.07 total=872753

Cool! This is one of those high level stats that gets you started on fixing problems.

(https://lwn.net/Articles/759781/)

What's coming in the next kernel release (part 1)

Posted Jan 1, 2019 20:28 UTC (Tue) by flussence (guest, #85566) [Link]

I get unusually high numbers on mine, probably an allergic reaction to MuQSS as the system's usually idle and responsive.
 ~ $ head /proc/pressure/*
==> /proc/pressure/cpu <==
some avg10=98.54 avg60=91.98 avg300=91.54 total=54064616695

==> /proc/pressure/io <==
some avg10=0.00 avg60=0.04 avg300=0.14 total=209725857
full avg10=0.00 avg60=0.00 avg300=0.00 total=1176

==> /proc/pressure/memory <==
some avg10=98.54 avg60=91.98 avg300=91.54 total=38856432564
full avg10=0.00 avg60=0.00 avg300=0.00 total=5130852

What's coming in the next kernel release (part 1)

Posted Jan 1, 2019 14:19 UTC (Tue) by nilsmeyer (guest, #122604) [Link] (1 responses)

Are we going to see WireGuard this time around?

What's coming in the next kernel release (part 1)

Posted Jan 1, 2019 14:46 UTC (Tue) by Margaret48 (guest, #129042) [Link]

No. No wireguard patches passed review yet. We're waiting for v9 revision.

What's coming in the next kernel release (part 1)

Posted Jan 8, 2019 2:24 UTC (Tue) by ghane (guest, #1805) [Link]

From the Adiantum git commit:
> We did find that some "lightweight" block ciphers are fast enough, but these suffer from problems such as not having much cryptanalysis or being too controversial.

:-)

--
Sanjeev


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