|
|
Subscribe / Log in / New account

The rest of the 6.3 merge window

By Jonathan Corbet
March 6, 2023
Linus Torvalds released 6.3-rc1 and closed the 6.3 merge window as expected on March 5. By that time, 12,717 non-merge commits (and 848 merges) had found their way into the mainline kernel; nearly 7,000 of those commits came in after the first-half merge-window summary was written. The second half of the 6.3 merge window was thus a busy time, with quite a bit of new functionality landing in the mainline.

Some of the most significant changes merged during this time are:

Architecture-specific

  • RISC-V kernels can use the "ZBB" bit-manipulation extension, when present, to accelerate string operations.
  • User-mode Linux (on x86-64 systems) now supports code written in Rust.
  • LoongArch has gained support for kernel relocation, kernel address-space layout randomization, hardware breakpoints and watchpoints, and kprobes.

Core kernel

  • It is now possible to create a non-executable memfd and prevent execute permission from being enabled thereafter.
  • The DAMOS memory-management interface has a new "filters" option; there is some documentation in this commit.
  • The new PR_SET_MDWE prctl() operation will cause any attempts to enable both write and execute permissions on memory in the target process to be denied; see this commit message for more information.

Filesystems and block I/O

  • The NFS filesystem (both the client and server sides) has gained support for AES-SHA2-based encryption.
  • The filesystems in user space (FUSE) subsystem has a new request extension mechanism that can be used to put additional information onto a request. The first use is to add supplementary groups to a filesystem request.
  • Christian Brauner has been added as a co-maintainer of the virtual filesystem (VFS) layer.

Hardware support

  • Clock: MediaTek MT7981 basic clocks, Qualcomm SM6350 camera clock controllers, Qualcomm SM8550 TCSR clock controllers, Qualcomm SM8550 display clock controllers, Qualcomm SA8775 and QDU1000/QRU1000 global clock controllers, and NXP BBNSM realtime clocks.
  • Graphics: Orise Technology ota5601a RGB/SPI panels, Visionox VTDR6130 1080x2400 AMOLED DSI panels, HIMAX HX8394 MIPI-DSI LCD panels, Intel "versatile processing unit" inference accelerators, and AUO A030JTN01 320x480 3.0" panels. Also, several ancient drivers (i810, mga, r128, savage, sis, tdfx, and via) have been removed; they were all marked as being obsolete in 2016.
  • Industrial I/O: TI TMAG5273 low-power linear 3D Hall-effect sensors, TI LMP92064 and ADS7924 analog-to-digital converters, Maxim MAX5522 digital-to-analog converters, and NXP IMX93 analog-to-digital converters.
  • Media: OmniVision OV8858 image sensors and Sony IMX296 and IMX415 sensors.
  • Miscellaneous: Unisoc UFS SCSI host controllers, Intel MAX 10 board management controllers with PMCI, Kinetic KTZ8866 backlight controllers, Microchip 8250-based serial ports, Ultrasoc system memory buffers, CoreSight trace, profiling, and diagnostics monitors, Qualcomm SDM670 and SA8775P interconnects, Freescale i.MX6/7/8 PCIe controllers in endpoint mode, Richtek RT9471 and RT9467 battery chargers, Loongson LS2X I2C adapters, GXP I2C Interfaces, Xilinx DMA/Bridge subsystem DMA engines, StarFive JH71XX power-management units, Renesas RZ/V2M external power sequence controllers, Allwinner D1 PPU power domain controllers, MediaTek SoC regulator couplers, Qualcomm ramp controllers, and Qualcomm PMIC GLINK interfaces.
  • USB: Renesas RZ/N1 USB function controllers, Renesas USB3.1 DRD controllers, Qualcomm SNPS eUSB2 PHYs, and Qualcomm SNPS eUSB2 repeaters.
  • Also: there is a new pata_parport driver that can manage IDE drives connected by way of a parallel port. With this driver, much of the work is done by the ATA layer, and the old PARIDE drivers have been removed. In this new world, it is no longer possible to put both drives and a printer on the port; this commit has some more information.

    (Ask your parents if you're unfamiliar with parallel ports and IDE drives.)

Miscellaneous

  • The Nolibc library has gained support for the s390 architecture and the Arm Thumb1 instruction set.
  • The new hwnoise tool can measure timing jitter caused by hardware; this commit contains a man page describing its operation.
  • The perf tool has seen a number of improvements; this merge message has details.
  • The kernel now can feature a built-in Dhrystone benchmark test.

Virtualization and containers

  • KVM on x86 has gained the ability to support Hyper-V extended hypercalls. These calls are implemented by passing them through to user space on the host side.
  • Also on x86, KVM has made it easier to restrict the performance-measurement-unit events that are available to the guest; this commit has more information.

Internal kernel changes

  • The internal __GFP_ATOMIC memory-allocation flag has been removed. Almost nobody should notice the change.
  • The (default) V=0 make option has been removed. The V=1 (verbose mode) and V=2 (show the reason why a target was rebuilt) can now be selected together as V=12.
  • There has been a minor change to the developer's certificate of origin to make it clear that patches submitted using a nickname are acceptable.
  • The internal representation of capabilities has been changed to a simple u64 value. The previous (array) representation had been designed to allow for more capabilities in the future, but as Torvalds noted in the changelog, "the last thing we want to do is to extend the capability set any more".
  • Support for building with the Intel ICC compiler has been removed. It has seemingly been broken for some time and nobody noticed.

The next seven or eight weeks will be spent stabilizing this new code in preparation for the 6.3 release, which should happen on April 23 or 30.

Index entries for this article
KernelReleases/6.3


to post comments

The rest of the 6.3 merge window

Posted Mar 6, 2023 17:45 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

> There has been a minor change to the developer's certificate of origin to make it clear that patches submitted using a nickname are acceptable.

Nice. I was worried that Asahi Lina's patches might be refused because of the requirement for the real name.

The rest of the 6.3 merge window

Posted Mar 6, 2023 22:39 UTC (Mon) by flussence (guest, #85566) [Link] (4 responses)

I wonder if the frequent complaints of subsystem maintainers obstructing that upstreaming work was what prompted this.

On a side note, this move is the polar opposite of something Gentoo's quietly been doing the past few months, cracking down on contributors of every tenure and ability solely for not providing a government-verifiable identity. My cynicism says they're doing it to ape current US politics, because the distro has historically courted people like that.

The rest of the 6.3 merge window

Posted Mar 7, 2023 9:33 UTC (Tue) by sima (subscriber, #160698) [Link]

It's been brewing for a long time because there's been long-established confusion between maintainers that always handled it in the "known identity" sense that Linus explains in the commit message, and some others (I think mostly exceptions as far as I know) who treated it more in the "the name that's on your passport" sense that "real name policy" has become to stand for. At least if you search lore hard enough you find mutterings along these lines a long while back, but it never was very loud.

The rest of the 6.3 merge window

Posted Mar 7, 2023 16:52 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

I would guess that the level of review is different. Kernel patches typically flow through a network of maintainers and get at least some attention. With Gentoo most packages have exactly one maintainer who looks at changes.

The rest of the 6.3 merge window

Posted Mar 7, 2023 17:41 UTC (Tue) by lfam (subscriber, #127309) [Link] (1 responses)

> On a side note, this move is the polar opposite of something Gentoo's quietly been doing the past few months, cracking down on contributors of every tenure and ability solely for not providing a government-verifiable identity. My cynicism says they're doing it to ape current US politics, because the distro has historically courted people like that.

Can you link to any context or discussion of this from Gentoo? I'm interested to learn more about it.

The rest of the 6.3 merge window

Posted Mar 20, 2023 23:21 UTC (Mon) by flussence (guest, #85566) [Link]

https://bugs.gentoo.org/900857 has been in filibuster purgatory until this year, and only because the kernel community's action here has pressured them into doing something. That's very much the tip of the iceberg, parts of the story are in 542498, 606562, 828973 and 895856 (and others, which I've long since lost track of).

Unfortunately nobody's done a cohesive writeup of any of it, and to do so would require deep-diving ~5 years of bugzilla, the -project mailing list (which doesn't seem to be archived anywhere with a usable UI), and… parts of the forums that were deleted outright a few years ago. That's another story entirely, but the short version is that a Large Corporate Sponsor decided it was a bad look for the distro to have no code of conduct or copyright attribution.

KVM hypercalls

Posted Mar 6, 2023 23:31 UTC (Mon) by geofft (subscriber, #59789) [Link]

I was curious what KVM had to do with Hyper-V hypercalls. The answer appears to be that it supports emulating Hyper-V's hypercalls for a guest OS - specifically Windows - that knows about Hyper-V but not about KVM paravirtualization. If you enable this feature, KVM identifies itself to the guest via CPUID as Hyper-V, not KVM. (That is, the new features have to do with Windows running under KVM, not with anything running under actual Hyper-V.)

https://www.qemu.org/docs/master/system/i386/hyperv.html

The rest of the 6.3 merge window

Posted Mar 7, 2023 7:06 UTC (Tue) by donald.buczek (subscriber, #112892) [Link] (13 responses)

> The kernel now can feature a built-in Dhrystone benchmark test.
> https://git.kernel.org/linus/d5528cc16893
> > author Geert Uytterhoeven <[email protected]> 2022-12-08 15:31:28 +0100
> > committer Andrew Morton <[email protected]> 2023-02-02 22:50:01 -0800
> > [...]
> > + * Author: Reinhold P. Weicker
> > + * Siemens AG, AUT E 51
> > + * Postfach 3220
> > + * 8520 Erlangen
> > + * Germany (West)
> > + * Phone: [+49]-9131-7-20330
> > + * (8-17 Central European Time)
> > + * Usenet: ..!mcsun!unido!estevax!weicker

Nice bit of nostalgia to have something with a bang path email address merged in 2023.

The rest of the 6.3 merge window

Posted Mar 7, 2023 7:32 UTC (Tue) by mb (subscriber, #50428) [Link] (3 responses)

*checking my calendar*.

Yeah, kind of nice.
The coding style is awful, though. And not very kernel like at all.
I would have expected it to be cleaned up before getting merged.
The kernel is not a museum for historic code dumps.

The rest of the 6.3 merge window

Posted Mar 8, 2023 1:29 UTC (Wed) by edeloget (subscriber, #88392) [Link] (1 responses)

> *checking my calendar*.

> Yeah, kind of nice.
> The coding style is awful, though. And not very kernel like at all.
>I would have expected it to be cleaned up before getting merged.
> The kernel is not a museum for historic code dumps.

I guess the style has been kept in order to make sure that the code was doing exactly what it says it does, including the "I need to make sure that the output can be compared to all other DMIPS outputs out there". I haven't looked the whole patch, but this may even come with special compiler options in order to make sure the compiler is not doing some nasty optimization that would lead to non-comparable results.

The rest of the 6.3 merge window

Posted Mar 8, 2023 9:13 UTC (Wed) by geert (subscriber, #98403) [Link]

Indeed, I only changed whitespace and basic formatting to please scripts/checkpatch.pl, to avoid impact on the measurements:
https://git.kernel.org/pub/scm/linux/kernel/git/geert/ren...
In theory, a synthetic benchmark can be optimized away entirely by a sufficiently smart compiler. That's also why the benchmark is split in two source files.

The figures cannot be compared accurately, as they depend heavily on compiler version and compiler options (some dictated by the kernel build system). They do work fine for my intended usage (verifying CPU core clock speeds), as DMIPS/MHz is reliable.

Typically, on e.g. arm32, I get 25% less DMIPS with the in-kernel version than with the userspace version (https://github.com/qris/dhrystone-deb.git).
Even with the latter, I saw differences up to 19% using gcc-4.9/6.3/7.4/8.3/9.3/10.2 (6.3 was worst, 10.2 was best).

The rest of the 6.3 merge window

Posted Mar 9, 2023 11:22 UTC (Thu) by Karellen (subscriber, #67644) [Link]

*checking my calendar*
Thu 10782 Sep 11:19:37 UTC 1993

Seems legit :-)

The rest of the 6.3 merge window

Posted Mar 7, 2023 8:46 UTC (Tue) by Sesse (subscriber, #53779) [Link] (2 responses)

I do feel like including Dhrystone is already nostalgia in itself! Now not only BogoMIPS, but actual, official MIPS…

The rest of the 6.3 merge window

Posted Mar 7, 2023 9:14 UTC (Tue) by geert (subscriber, #98403) [Link]

Now we just need someone to try it on linux-vax ;-)

The rest of the 6.3 merge window

Posted Mar 13, 2023 7:44 UTC (Mon) by anton (subscriber, #25547) [Link]

BogoMIPS are real MIPS (although for a pointless loop), while AFAIK Dhrystone MIPS are based on the idea that a VAX 11/780 executes the Dhrystone benchmark at 1 (VAX) MIPS; however, from what I read, the VAX 11/780 typically ran at 0.5MIPS (about 10 cycles/instruction at 5MHz clock rate), so DMIPS were not real MIPS even on the VAX. These days we can determine the number of instructions executed by Dhrystone easily with perf stat -e instructions.

The rest of the 6.3 merge window

Posted Mar 7, 2023 13:30 UTC (Tue) by amw (subscriber, #29081) [Link] (4 responses)

Not to mention the "Germany (West)".

The rest of the 6.3 merge window

Posted Mar 7, 2023 13:36 UTC (Tue) by timon (guest, #152974) [Link] (3 responses)

... and, more subtly, the 4-digit postal code.

The rest of the 6.3 merge window

Posted Mar 7, 2023 13:43 UTC (Tue) by amw (subscriber, #29081) [Link]

I was going to mention that, but then thought better of it.

The rest of the 6.3 merge window

Posted Mar 7, 2023 19:50 UTC (Tue) by geert (subscriber, #98403) [Link]

OMG, Erlangen used to have a MOS Technology Complex Interface Adapter postal code ;-)

The rest of the 6.3 merge window

Posted Mar 8, 2023 0:24 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

And now I've spent 2 hours reading about the postal system in Germany.

I blame you.

The rest of the 6.3 merge window

Posted Mar 7, 2023 20:46 UTC (Tue) by MarcB (subscriber, #101804) [Link]

> Nice bit of nostalgia to have something with a bang path email address merged in 2023.

It nicely matches the pre-1993, four-digit German postal code and the "Germany (West)" country designation :-)


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