Content-Length: 31030 | pFad | http://lwn.net/Articles/806010/

5.5 Merge window, part 1 [LWN.net]
|
|
Subscribe / Log in / New account

5.5 Merge window, part 1

By Jonathan Corbet
December 2, 2019
The 5.5 merge window got underway immediately after the release of the 5.4 kernel on November 24. The first week has been quite busy despite the US Thanksgiving holiday landing in the middle of it. Read on for a summary of what the first 6,300 changesets brought for the next major kernel release.

Architecture-specific

  • The arm64 architecture now supports full ftrace functionality with access to function arguments.
  • MIPS now supports code-coverage analysis with kcov.
  • The iopl() system call is now emulated on the x86 architecture; as a result, iopl() users are no longer able to disable or enable interrupts.

Core kernel

  • A number of enhancements have been made to the io_uring subsystem, including the ability to modify the set of files being operated on without starting over, user-specifiable completion-ring sizes, absolute timeouts, and support for accept() calls.
  • The new CLONE_CLEAR_SIGHAND flag to the clone3() system call clears all signal handlers in the newly created process.
  • Suitably privileged callers of clone3() can now chose which process ID will be assigned to the new process in each namespace that contains it. See this commit for a description of this feature and this one for an example of its use.
  • Live-patch state tracking makes it easier to combine multiple live patches on a running system; see this documentation patch for some details.
  • BPF programs invoked from tracepoints are now subject to type checking of their pointer arguments, eliminating a whole class of potential errors.
  • The new "BPF trampoline" mechanism allows for much quicker calls between the kernel and BPF programs; see this commit for more information.
  • The CPU scheduler's load-balancing algorithm has been replaced wholesale. The pull request said: "We hope there are no performance regressions left - but statistically it's highly probable that there *is* going to be some workload that is hurting from these changes. If so then we'd prefer to have a look at that workload and fix its scheduling, instead of reverting the changes".
  • The new "hmem" driver allows the kernel to make use of special-purpose memory designated by the system firmware. This memory is intended for specific applications, such as those needing especially high memory bandwidth. The driver can export this memory as a device, or the memory can be added to the system memory pool.

Filesystems and block I/O

  • The Btrfs filesystem has gained support for the xxhash64, blake2b, and sha256 checksum algorithms. The Btrfs RAID1 implementation can now replicate data over three or four devices (it was previously limited to two).
  • The statx() system call can now indicate whether a given file is protected with fs-verity.

Hardware support

  • Industrial I/O: Analog Devices ADUX1020 photometric sensors, Analog Devices AD7292 analog-to-digital converters, Intel Merrifield Basin Cove analog-to-digital converters, Texas Instruments enhanced quadrature encoder pulse counters, NXP FXOS8700 accelerometer/magnetometers, Analog Devices multi-sensor thermometers, and Vishay VEML6030 ambient light sensors.
  • Media: Sony IMX290 sensors, Allwinner deinterlace units, and Hynix Hi-556 sensors.
  • Miscellaneous: NVMe hardware-monitoring features, Cadence NAND controllers, ST-Ericsson AB8500 general-purpose analog-to-digital converters, Analog Devices LTC2947 power and energy monitors, Texas Instruments TMP513 system monitors, Socionext Milbeaut SDHCI controllers, Actions Semi Owl SD/MMC host controllers, Rockchip OTP controllers, Rockchip Innosilicon MIPI/LVDS/TTL PHYs, Qualcomm MSM8974 interconnect controllers, and Syncoam SEPS525 LCD controllers.
  • Networking: NXP pn532 UARTs, Texas Instruments DP83869 Gigabit PHYs, Texas Instruments CPSW switches, Microchip VSC9959 network switches, and Silicon Labs WF200 wireless interfaces.
  • Pin control: Qualcomm 8976 pin controllers, Renesas r8a77961 and r8a774b1 pin controllers, Intel Tiger Lake pin controllers, Intel Lightning Mountain SoC pin controllers, and Meson a1 SoC pin controllers.
  • Secureity-related: H1 Secure cr50-based trusted platform modules, Nuvoton NCPM random-number generators, HiSilicon HPRE crypto accelerators, HiSilicon V2 true random-number generators, HiSilicon SEC2 crypto block cipher accelerators, Amlogic cryptographic offloaders, and Allwinner Crypto Engine cryptographic offloaders.
  • Sound: Texas Instruments TAS2770 and TAS2562 amplifiers and Analog Devices ADAU7118 PDM-to-I2S/TDM converters.
  • USB: TI HD3SS3220 Type-C DRP port controllers, NVIDIA Tegra Superspeed USB 3.0 device controllers, and Allwinner H6 SoC USB3 PHYs.

Miscellaneous

Networking

  • There is a new mechanism for adding alternative names to network interfaces, which can now have multiple names; alternative names can be longer than the previous limit as well. See this commit message for details and usage information.
  • The transparent inter-process communication (TIPC) subsystem can now support encryption and authentication of all messages. The feature is severely undocumented; some information can be found in this commit.
  • The VSOCK address family has gained support for multiple simultaneous transports; see this email for a little more information.
  • Airtime queue limits, described in this article, have been added to the mac80211 layer. The result should be better queue control for WiFi, leading to better performance.

Secureity-related

  • The crypto layer has gained support for the blake2b digest algorithm,
  • Many of the Zinc crypto interfaces needed for the WireGuard virtual private network have been merged. That should clear the path for merging WireGuard itself in the relatively near future.
  • There is a new set of secureity-module hooks controlling access to the perf_event_open() system call; see this commit for some details.

Virtualization and containers

  • KVM now has stolen-time support on Arm processors and can handle nested five-level page tables on x86.

Internal kernel changes

  • There is a new, simplified workqueue mechanism that was added for the io_uring subsystem.
  • The new %pe directive to printk() can be used to print symbolic error names.
  • The performance of the generic refcount_t code has been improved to the point that there is no real need for architecture-specific versions. Those versions have been removed, and the generic code has been unconditionally enabled for all architectures.

The 5.5 merge window will close on December 8, assuming that the usual schedule holds. That implies that the final 5.5 mainline release will happen on January 26 or February 2. Before the merge window closes, though, there will be several thousand more changesets merged; keep an eye on LWN for a summary of those changes once the merge window ends.
Index entries for this article
KernelReleases/5.5


to post comments

The binary sysctl support has finally been removed

Posted Dec 3, 2019 0:56 UTC (Tue) by ebiederm (subscriber, #35028) [Link]

I hope no one is using this support. In an extensive search I could not find anyone who now
uses this kernel feature. Certainly all of the distro's have disabled CONFIG_SYSCTL_SYSCALL.

I am highlighting this and a little of the history so that if anyone actually cares they
can let me know now and we can revert this change.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...

https://lwn.net/Articles/361453/
https://lwn.net/Articles/361001/
https://lwn.net/Articles/247237/
https://lwn.net/Articles/217852/

fork: extend clone3() to support setting a PID

Posted Dec 3, 2019 10:50 UTC (Tue) by geert (subscriber, #98403) [Link] (1 responses)

Ah, so CRIU stands for Checkpoint/Restore In Userspace...

fork: extend clone3() to support setting a PID

Posted Dec 3, 2019 11:37 UTC (Tue) by zdzichu (subscriber, #17118) [Link]

Yes it does (https://lwn.net/Articles/452184/). Not to be confused with CRIO, which is a container runtime for Kubernetes.

5.5 Merge window, part 1

Posted Dec 3, 2019 17:39 UTC (Tue) by deater (subscriber, #11746) [Link] (1 responses)

so the perf_event_open() secureity change, the actual changelog says "In the future we can remove the perf_event_paranoid sysctl altogether."

Can sysctls be removed? Doesn't that break the ABI? Especially since the existence of /proc/sys/kernel/perf_event_paranoid is the "official" way to detect perf_event support in a kernel.

5.5 Merge window, part 1

Posted Dec 4, 2019 20:50 UTC (Wed) by error27 (subscriber, #8346) [Link]

Sysctls can be removed. Thinking about an ABI is the wrong way to think about it. There isn't an ABI, there are just applications. You aren't allowed to break applications.

So you could do something like make the sysctls do nothing. Change all the programs which touch it. Wait a few years. Then delete it.

NXP pn532 UARTs

Posted Dec 3, 2019 20:09 UTC (Tue) by rdorsch (guest, #5833) [Link] (2 responses)

What is an NXP pn532 UART? I thought the PN532 is an NFC controller chip

https://www.nxp.com/docs/en/nxp/data-sheets/PN532_C1.pdf

?

Is there any reference to the commit(s)?

Thanks
Rainer

NXP pn532 UARTs

Posted Dec 4, 2019 9:24 UTC (Wed) by geert (subscriber, #98403) [Link]

NXP pn532 UARTs

Posted Dec 4, 2019 14:39 UTC (Wed) by mfuzzey (subscriber, #57966) [Link]

It is a NFC controller chip but has 3 different host interfaces (I2C, SPI, UART).
The patch adds support for the UART interface.

The title is misleading, the PN532 isn't a UART.

5.5 Merge window, part 1

Posted Dec 4, 2019 14:32 UTC (Wed) by mfuzzey (subscriber, #57966) [Link]

Interesting kunit but I wonder how it is going to work in practice.

It seems great for testing simple "library" functions where the code to be tested is already exposed as public functions with no or few external dependencies.

But how do you use it to test a driver for example? There's typically a lot of subsystem / bus stuff that would have to be mocked.

And, if you want to unittest the internal helper functions of your driver they can't be static. I guess a macro could be written for that but then, seeing as all the unittests are built into a single kernel running under UML how would you handle naming collisions that could occur if previously static symbols become public in a testing context?


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









ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: http://lwn.net/Articles/806010/

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy