|
|
Subscribe / Log in / New account

The second half of the 5.13 merge window

By Jonathan Corbet
May 10, 2021
By the time the last pull request was acted on and 5.13-rc1 was released, a total of 14,231 non-merge commits had found their way into the mainline. That makes the 5.13 merge window larger than the entire 5.12 development cycle (13,015 commits) and just short of all of 5.11 (14,340). In other words, 5.13 looks like one of the busier development cycles we have seen for a little while. About 6,400 of these commits came in after the first-half summary was written, and they include a number of significant new features.

Changes merged in the second half of the 5.13 merge window include:

Architecture-specific

  • The arm64 architecture has settled on SPARSEMEM_VMEMMAP as the only supported memory-management model.
  • 32-Bit PowerPC systems now have support for extended BPF and the KFENCE debugging system.
  • PowerPC systems now support time namespaces.
  • The RISC-V architecture has gained support for kexec, crash dumps via kexec, execute-in-place, and kprobes.
  • s390 systems can now do stack-offset randomization in system-call handlers.

Core kernel

  • BPF tracing programs may now make use of task-local storage, which provides a number of performance benefits over using maps.
  • There is a new mechanism by which BPF programs can call kernel functions directly; its initial use is in the implementation of TCP congestion-control algorithms. Functions must be explicitly whitelisted to be made available for calling from BPF. Some information can be found in this commit.
  • The function tracer (ftrace) has a new func-no-repeats option that causes multiple, consecutive calls to a function to be coalesced into a simple count in the output.
  • User-space page-fault handling with userfaultfd() can now manage minor faults (those where a valid page exists but a valid page-table entry does not). See this commit for information on this feature and how it is meant to be used.
  • The old (but dangerous) /dev/kmem special file, which provided access to the kernel's address space, has been removed at last.

Filesystems and block I/O

  • The exFAT filesystem has gained support for the FITRIM ioctl() command, which is used to inform the storage device about blocks that are no longer used.
  • The XFS filesystem now can remove space from the last allocation group in the filesystem; this is a first step toward the ability to shrink XFS filesystems in general.
  • There is a new quota-related system call:

        int quotactl_path(unsigned int cmd, const char *mountpoint, qid_t id,
        		      void *addr);
    
    Its behavior is similar to quotactl(), except that it expects the path to the mount point of a filesystem rather than the block special device holding that filesystem.
  • The fanotify mechanism has always restricted a number of features to privileged users, but some of those restrictions have been removed for 5.13. See this commit for a cryptic description of what's allowed and what is not.
  • The ext4 filesystem will now overwrite directory entries when files are deleted. Ext4 can now also handle filesystems that use both case folding and encryption.

Hardware support

  • Human-interface devices: FTDI FT260 USB HID to I2C host bridges, Microsoft Surface system aggregator module HID transports, Azoteq IQS626A capacitive touch controllers, MStar msg2638 touchscreens, Ilitek I2C 213X/23XX/25XX/Lego series touch controllers, and Hycon hy46xx touchscreens.
  • Miscellaneous: Silicon Labs CP2615 USB I2C adapters, HiSilicon I2C controllers, Unisoc IOMMUs, Intel Data Accelerators performance monitors, Toshiba Visconti pulse-width modulators, MediaTek Gen3 PCIe controllers, and SiFive FU740 PCIe host controllers.
  • Networking: Marvell 88X2222 PHYs, Broadcom BCM6368 MDIO bus multiplexers, Actions Semi Owl Ethernet MACs, Microsoft Azure network adapters, NXP C45 TJA11XX PHYs, and Microchip KSZ8863 and KSZ8873 switches.
  • Pin control: Broadcom BCM63xx GPIO controllers, Mediatek MT8195 pin controllers, Xilinx ZynqMP pin controllers, and Realtek Otto GPIO controllers.
  • Sound: Realtek RT1316 codecs, Realtek RT711 and RT715 SDCA codecs, Realtek RT1019 mono class-D audio amplifiers, and MediaTek MT6359 ACCDET jack controllers.
  • Virtio: new virtio drivers have been added for Bluetooth controllers and sound devices.

Security-related

  • After years of work and 34 revisions, the Landlock security module has finally been merged.

    The goal of Landlock is to enable to restrict ambient rights (e.g. global filesystem access) for a set of processes. Because Landlock is a stackable LSM, it makes possible to create safe security sandboxes as new security layers in addition to the existing system-wide access-controls.

    See landlock.io for more information.

Internal kernel changes

  • vmalloc() can now create huge-page mappings.
  • There are some new functions for allocating batches of pages in a single call: alloc_pages_bulk() and alloc_pages_bulk_array(). Documentation is scarce, but some information can be found in this commit and this one.
  • See also this article for more information on both of the above changes.

One feature that failed to make it this time around is the proposed memfd_secret() system call, which creates areas of memory that are hidden from the rest of the system (including the kernel). Andrew Morton expressed doubts about the utility of the feature, which brought out a few potential users saying that they would like to have it. Morton now appears to be convinced but, by the time that happened, it was too late for 5.13. So memfd_secret() looks set to make its appearance in 5.14 instead.

If the 5.13 kernel is released after seven -rc cycles, it will come out on June 27; if a -rc8 is required, 5.13 will supply an added cause for fireworks and celebration in the US on July 4. There will need to be a lot of testing and fixing between now and then and, if past experience holds, approximately 2,000 more commits. The merge window is done, but there is still a fair amount of work to be done to get the next kernel release out.

Index entries for this article
KernelReleases/5.13


to post comments

The second half of the 5.13 merge window

Posted May 11, 2021 5:11 UTC (Tue) by smurf (subscriber, #17840) [Link] (3 responses)

> quotactl_path

Wait, a new path-related system call without a fd_at argument and without flags?

Looks like "lesson not learned" to me.

The second half of the 5.13 merge window

Posted May 11, 2021 6:48 UTC (Tue) by matthias (subscriber, #94967) [Link] (2 responses)

Should be ok for this syscall. This is a quite complex syscall that takes a cmd field and a structure. If the need for flags arises, they can be put into the cmd field or the structure. Also, an additional flags field would make no sense at all. This syscall should behave like the quotactl syscall, which does not have flags. Thus any needed flags would be put into the existing cmd field and structure anyway, even if the new syscall would get a flags field.

The second half of the 5.13 merge window

Posted May 11, 2021 18:20 UTC (Tue) by nybble41 (subscriber, #55106) [Link] (1 responses)

> This is a quite complex syscall that takes a cmd field and a structure.

Each command takes a *different* structure, or in some cases no structure at all. And not all of the structures are versioned to allow them to be extended with extra fields. A new system call which takes a path string but no fd_at argument or flags related to path resolution (RESOLVE_BENEATH, RESOLVE_IN_ROOT, etc.) seems like a step backward to me as well. These ought to be standard for any new path-based system call.

The second half of the 5.13 merge window

Posted May 12, 2021 11:08 UTC (Wed) by jan.kara (subscriber, #59161) [Link]

Guys, these are good points for consideration. Thanks for them. Sadly, nobody pointed these out when this syscall was posted to linux-api mailing list back in March. Maybe you should hang out there? ;) Anyway, AFAIK there's no userspace using this syscall yet and it hasn't been released in a major release so we still have a few weeks to decide what to do. I've resumed the discussion in relevant mailing lists...


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