|
|
Subscribe / Log in / New account

The rest of the 4.16 merge window

By Jonathan Corbet
February 12, 2018
At the close of the 4.16 merge window, 11,746 non-merge changesets had been merged; that is 5,000 since last week's summary. This merge window is thus a busy one, though not out of line with its predecessors — 4.14 had 11,500 changesets during its merge window, while 4.15 had 12,599. Quite a bit of that work is of the boring internal variety; over 600 of those changesets were device-tree updates, for example. But there was still a fair amount of interesting work merged in the second half of the 4.16 merge window; read on for the highlights.

Architecture-specific

Core kernel

  • The expedited option has been added to the membarrier() system call. The API has changed somewhat since it was last discussed, though. At that time, there was a concern about not perturbing processes that did not need to participate in any given barrier operation, and some complex schemes for figuring out which processes to include. The merged patches, though, create an opt-in mechanism for processes that want to participate in "global" barrier operations. Opting in is a matter of calling membarrier() with the concise and easy-to-type MEMBARRIER_CMD_REGISTER_GLOBAL_EXPEDITED command. An expedited barrier can be sent to all registered processes with MEMBARRIER_CMD_GLOBAL_EXPEDITED.

Filesystems and block I/O

  • Overlay filesystems using overlayfs can now be exported via NFS. Enabling this functionality changes some overlayfs behavior and can create a filesystem that is not backward compatible; see the documentation in this commit and this commit for details.
  • The XFS reverse-mapping feature is no longer marked as being experimental.
  • The AFS filesystem has "dynamic root" support; see this commit for more information.

Miscellaneous

  • The new console_msg_format command-line option can be used to adjust the formatting of printk() output. In particular, setting it to syslog will cause a syslog-like format to be generated.
  • Virtualization with KVM now supports AMD's secure encrypted virtualization (SEV) feature.

Security-related

  • The usercopy whitelisting patch set has been merged. This mechanism further reduces the ranges of memory that can be copied to or from user space; now specific fields of a slab-allocated structure can be whitelisted. After some discussion, the current configuration will only issue a warning (rather than oopsing the system) if non-whitelisted memory is copied; the intent is to find and fix any problems without actually breaking the kernel when those problems occur. When the developers are confident that all of the issues have been found, that behavior may change in a more unforgiving direction.

    Anybody wanting stricter behavior now can disable the HARDENED_USERCOPY_FALLBACK configuration option or set the slab_common.usercopy_fallback command-line option to zero.

  • Initial mitigations for Spectre variant 1 (bounds-check bypass) have been merged; see this article for details. The core of this support is a new array_index_nospec() macro that prevents speculation that might cause a bounds check to be circumvented.
  • The arm64 architecture has gained another set of Meltdown/Spectre mitigations. The array_index_nospec() operator is supported natively, and it has been applied in a few places in the kernel. Branch-predictor hardening has been improved as well.
  • S390 has also gained an implementation of array_index_nospec(), support for some new instructions to control branch prediction, and a variant on the retpoline concept called an "expoline".

Hardware support

  • Clock: Hisilicon Hi3660 stub clocks, Spreadtrum SC9860 clocks, Qualcomm MSM8916 APCS clock controllers, AmLogic A113D clock controllers, and Freescale MXC realtime clocks.
  • Pin control Meson AXG pin-control units, STMicroelectronics STM32MP157 and STM32F769 pin controllers, MediaTek MT7622 pin control units, Microsemi Ocelot pin control units, and Qualcomm MSM8998 pin controllers.
  • Media: NXP TDA18250 silicon tuners, NVIDIA Tegra video decoder engines, Intel IPU3 CIO2 CSI-2 receivers, and OmniVision OV7740 sensors.
  • Miscellaneous: Ilitek ILI9225 and ILI9322 display panels, OpenCAPI coherent accelerators, Cadence PCIe host controllers, Realtek RTD119x/RTD129x watchdog timers, and Spreadtrum watchdog timers.
  • The old-style LIRC infrared controller drivers, having languished in staging for the requisite number of cycles, have now been removed from the kernel.

Internal kernel changes

  • The way that printk() handles large amounts of message traffic has been changed. It will now spread the work over multiple CPUs, reducing the possibility of locking up a CPU with constant message traffic.
  • The i2c-gpio fault injector can be used to create "unusual states" on the I2C bus to test the other side's error handling; see Documentation/i2c/gpio-fault-injection for details.

Barring a Meltdown-style security issue or some other problem of that magnitude, the final 4.16 release can be expected in early April. As always, though, there is a lot of testing and fixing to be done between now and then.

Index entries for this article
KernelReleases/4.16


to post comments

The rest of the 4.16 merge window

Posted Feb 12, 2018 19:50 UTC (Mon) by willy (subscriber, #9762) [Link] (3 responses)

I'd like to plug a couple of improvements I made to the IDR API here:
  • Better support for numbering schemes that don't start at 0. If you declare/initialise your IDR with DECLARE_IDR_BASE(name, base); or idr_init_base(&idr, base); then you'll get a performance improvement (and a miniscule memory improvement).
  • Support for writing the object ID to the object before inserting it into the IDR. If you use the IDR with lockless lookups, you currently have to cope with finding an object that doesn't know what ID it has. The new idr_alloc_u32() function ensures the ID is initialised before the pointer is stored in the array (and, yes, it has the appropriate memory barriers).

The rest of the 4.16 merge window

Posted Feb 12, 2018 20:52 UTC (Mon) by tpo (subscriber, #25713) [Link] (2 responses)

What's IDR?

The rest of the 4.16 merge window

Posted Feb 12, 2018 21:00 UTC (Mon) by willy (subscriber, #9762) [Link] (1 responses)

That is a great question! Thank you for asking it! I should not have assumed that my audience here would know what it is.

IDR is an ID allocator. It's been around for over 15 years, but people keep insisting on writing their own ID allocators, not realising that largely they're not better than using the one we already have. I've been making some improvements to it over the past couple of years, mostly spurred by my interest in the radix tree.

Its API can be found here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...
and there is some fairly spartan documentation here:
https://www.kernel.org/doc/html/latest/core-api/idr.html

Please let me know if you have any suggestions for improvement.

IDR

Posted Feb 12, 2018 21:04 UTC (Mon) by corbet (editor, #1) [Link]

Various LWN articles on IDR can also be found via the kernel index.

The rest of the 4.16 merge window

Posted Feb 13, 2018 1:58 UTC (Tue) by flussence (guest, #85566) [Link] (1 responses)

The level of activity this cycle seems to have taken a steep dive, which is good while we're all recovering from January, but it also makes it pretty obvious that some vendors still think “LTS” means “Last one There Stinks”.

The rest of the 4.16 merge window

Posted Feb 13, 2018 12:58 UTC (Tue) by willy (subscriber, #9762) [Link]

The article:

> 11,746 non-merge changesets had been merged; that is 5,000 since last week's summary. This merge window is thus a busy one, though not out of line with its predecessors — 4.14 had 11,500 changesets during its merge window, while 4.15 had 12,599.

Your comment:

> The level of activity this cycle seems to have taken a steep dive

I can't reconcile these two statements. 6.7% reduction isn't "a steep dive".

The rest of the 4.16 merge window

Posted Feb 13, 2018 10:09 UTC (Tue) by jezuch (subscriber, #52988) [Link] (5 responses)

> The XFS reverse-mapping feature is no longer marked as being experimental.

I'm curious about the ramifications of this. Is this the one that allows snapshots and deduplication in XFS? Does that mean that these features are new stable?

The rest of the 4.16 merge window

Posted Feb 13, 2018 12:01 UTC (Tue) by Sesse (subscriber, #53779) [Link] (1 responses)

From the 4.8 announcement:

“This reverse mapping infrastructure is the building block of several upcoming features - reflink, copy-on-write data, dedupe, online metadata and data scrubbing, highly accurate bad sector/data loss reporting to users, and significantly improved reconstruction of damaged and corrupted filesystems. There's a lot of new stuff coming along in the next couple of cycles, and it all builds in the rmap infrastructure. ”

I don't know if snapshots and deduplication is marked as stable yet, but I believe online fsck (well, scrub) is now no longer experimental.

The rest of the 4.16 merge window

Posted Feb 13, 2018 15:29 UTC (Tue) by wazoox (subscriber, #69624) [Link]

It is experimental, and largely incomplete. The xfs_scrub utility is still more or less alpha and should land as a check-only tool (no repair capability) in xfsprogs 4.15.0.

The rest of the 4.16 merge window

Posted Feb 13, 2018 13:44 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

Reflinks were marked not-experimental right before rmap, so deduplication is not experimental any more (but you'll need to re-mkfs to use it if your filesystem was not mkfsed with the appropriate options).

XFS doesn't have in-fs snapshot support yet, not even experimentally.

The rest of the 4.16 merge window

Posted Feb 13, 2018 20:28 UTC (Tue) by willy (subscriber, #9762) [Link]

> XFS doesn't have in-fs snapshot support yet, not even experimentally.

Depends how willing you are to break into Dave Chinner's hard drive and steal his code ...

https://www.spinics.net/lists/linux-xfs/msg15334.html

The rest of the 4.16 merge window

Posted Feb 17, 2018 17:44 UTC (Sat) by jezuch (subscriber, #52988) [Link]

> (but you'll need to re-mkfs to use it if your filesystem was not mkfsed with the appropriate options)

That's a pity :) But it's great anyway, thanks!


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