5.12 merge window, part 2 [LWN.net]

By Jonathan Corbet
March 1, 2021

The 5.12 merge window closed with the release of 5.12-rc1 on February 28; this released followed the normal schedule despite the fact that Linus Torvalds had been without power for the first six days after 5.11 came out. At that point, 10,886 non-merge changesets had found their way into the mainline repository; about 2,000 of those showed up after the first-half merge-window summary was written. The pace of merging obviously slowed down, but there were still a number of interesting features to be found in those patches.

Architecture-specific

The RISC-V architecture has gained support for non-uniform memory access (NUMA) systems. This architecture also now supports kprobes, uprobes, and per-task stack canaries.

Core kernel

The kcmp() system call can now be configured into the system independently of the checkpoint/restore functionality.

Filesystems and block I/O

ID mapping for mounted filesystems, which has seen several proposed implementations over the years, has been merged at last. See this merge message for more information. This functionality is currently supported by the FAT, ext4, and XFS filesystems.
The NFS client implementation has gained support for "eager writes". When this option is enabled (at mount time), file writes are sent immediately to the server rather than sitting in the page cache. This can reduce memory pressure on the client, provide immediate notification if the filesystem fills up, and can even evidently improve throughput for some workloads.
The CIFS ("SMB") filesystem has a couple of new mount options to control the caching of file (acregmax) and directory (acdirmax) metadata.

Hardware support

Miscellaneous: Playstation DualSense gamepads and force-feedback game controllers, Nintendo 64 game controllers, Nintendo 64 data cartridges, Intel Lightning Mountain centralized DMA controllers, Compute Express Link 2.0 type-3 memory devices, Broadcom VK accelerators, Qualcomm MSM8939 and SDX55 interconnect buses, Microchip AXI PCIe host bridges, Intel LGM SSO LED controllers, and Canaan Kendryte K210 reset controllers, pin control units, and clock controllers.
Pin control: R-Car V3U pin controllers, Allwinner H616 pin controllers, and Qualcomm SM8350 and SC8180x pin controllers.

Miscellaneous

The user-space perf-events tools have gained a number of new features, including the ability to report on instruction latency and a new daemon mode for long-running sessions. See this merge changelog for more information.

Virtualization and containers

Support for the ACRN hypervisor has been added.

Internal kernel changes

The build system now can use Clang's link-time optimization (LTO) features on the Arm64 and x86 architectures. Android builds have been using LTO for a while, but now this capability is in the mainline as well. See this commit and this commit for (some) more information.
The EXPORT_UNUSED_SYMBOL() and EXPORT_SYMBOL_GPL_FUTURE() macros have been removed, since there have been no users of them in the kernel for years.
A new memory-debugging tool called "kfence" has been merged; it can find a number of types of errors (use-after-free, buffer overflow, etc.) and features a low-enough overhead, it seems, to be usable on production systems. See this documentation commit for more information.
The core of the io_uring subsystem has been reworked to stop using kernel threads; instead, when work must be done in thread context, a new thread is forked from the calling process. This should result in no user-visible changes other than, it is hoped, a reduction in bugs from the removal of some problematic kernel code.

The 5.12 kernel has now entered the stabilization part of the development cycle. Unless something surprising happens, the final 5.12 release can be expected on April 18 or 25. Given that, seemingly, even record-breaking winter storms are unable to slow down the pace of kernel development, that something would have to be surprising indeed.

Index entries for this article
Kernel	Releases/5.12

to post comments

5.12 merge window, part 2

Posted Mar 2, 2021 9:37 UTC (Tue) by patrakov (subscriber, #97174) [Link] (2 responses)

Is there any reason why Btrfs does not support ID mapping?

5.12 merge window, part 2

Posted Mar 2, 2021 15:44 UTC (Tue) by mss (subscriber, #138799) [Link] (1 responses)

Probably nobody simply implemented this support yet.

5.12 merge window, part 2

Posted Mar 2, 2021 23:58 UTC (Tue) by brauner (subscriber, #109349) [Link]

The hope is to implement this real soon. A friend of mine and close collaborator has already expressed interest in porting btrfs.

5.12 merge window, part 2

Posted Mar 2, 2021 12:20 UTC (Tue) by karkhaz (subscriber, #99844) [Link] (1 responses)

> A new memory-debugging tool called "kfence" has been merged; it can find a number of types of errors (use-after-free, buffer overflow, etc.) and features a low-enough overhead to, it seems, be usable on production systems. See this documentation commit for more information.

Cool, looking forward to trying this out! This seems like a fairly low-effort way for testing new stable kernels before deploying them---compile the kernel with KFENCE and run various workloads on a test machine for some days, perhaps with KFENCE_NUM_OBJECTS and KFENCE_SAMPLE_INTERVAL set to much higher values to be able to show bugs up more quickly.

5.12 merge window, part 2

Posted Mar 2, 2021 17:58 UTC (Tue) by melver (subscriber, #134990) [Link]

While KFENCE was designed to be deployed at scale and for our use-cases are looking at KFENCE_SAMPLE_INTERVAL >= 500 milliseconds, I'm also aware of a KFENCE deployment where they chose KFENCE_SAMPLE_INTERVAL=1 ms (and lower with experimental patches) and very large KFENCE_NUM_OBJECTS (65535 -> 512 MiB) and found bugs that way. For such aggressive configs, see what performance you get, but my guess is that at sample intervals as low as 1 ms, you'll want to switch to KFENCE's non-static-branch mode with CONFIG_KFENCE_STATIC_KEYS=n.

5.12 merge window, part 2

Posted Mar 2, 2021 15:23 UTC (Tue) by alonz (subscriber, #815) [Link]

> idmapped mounts will be used in the
> implementation of portable home directories in
> systemd-homed.service(8) where they allow users to move their home
> directory to an external storage device and use it on multiple
> computers where they are assigned different uids and gids. This
> effectively makes it possible to assign random uids and gids at
> login time.

I can already see the consternation this will cause with various folks... "Random UID? WTF??!?"
I'm not sure how systems will adapt to such a situation, but (once the bugs are ironed out) I am certain this will aid security, at least slightly.

5.12 merge window, part 2

Posted Mar 14, 2021 19:17 UTC (Sun) by nix (subscriber, #2304) [Link]

> The NFS client implementation has gained support for "eager writes".

I'm slobbering at this. I've always been unhappy at the fact that lazy writeback on NFS clients essentially waits for *two* rounds of writeback (once on the client, then once on the server) and discards any write errors even more badly than lazy writeback on local filesystems already does (-ENOSPC is the big one, but not the only one).

Time to flip on write=wait everywhere as soon as it's supported (I have a mixture of machines where -ENOSPC would mean data loss, and machines on 10GbE where it seems most unlikely that write=wait would incur any slowdowns).