|
|
Subscribe / Log in / New account

The 4.5 merge window opens

By Jonathan Corbet
January 13, 2016
As of this writing, just over 3,100 non-merge changesets have been pulled into the mainline repository for the 4.5 development cycle. As one would expect three days into the merge window, things are just getting started. Nonetheless, a number of significant changes have already been pulled. Some of the more interesting of those are:

  • The device mapper's dm-verity subsystem, which is charged with validating the integrity of data on the underlying storage device, has gained the ability to perform forward error correction. This allows for the recovery of data from a device where "several consecutive corrupted blocks" exist. The first consumer for this appears to be Android, which uses dm-verity already.

  • As usual, there is a long list of improvements to the perf events subsystem; see this merge commit for a detailed summary.

  • Mandatory file locking is now optional at configuration time. This is a first step toward the removal (sometime in the distant future) of this unloved and little-used feature.

  • The copy_file_range() system call has been merged. It allows for the quick copying of a portion of a file, with the operation possibly optimized by the underlying filesystem. The support code for copy_file_range() has also enabled an easy implementation of the NFSv4.2 CLONE operation.

  • The User-Mode Linux port now supports the seccomp() system call.

  • The SOCK_DESTROY operation, allowing a system administrator to shut down an open network connection, is now supported.

  • The "clsact" network queueing discipline module has been added; see this commit changelog for details and usage information.

  • The "version 2" control-group interface is now considered official and non-experimental; it can be mounted with the cgroup2 filesystem type. Not all controllers support this interface yet, though. See Documentation/cgroup-v2.txt for details on the new interface.

  • New hardware support includes:

    • Cryptographic: Rockchip cryptographic engines and Intel C3xxx, C3xxxvf, C62x, and C62xvf cryptographic accelerators.

    • Miscellaneous: HiSilicon MBIGEN interrupt controllers, Technologic TS-4800 interrupt controllers, and Cirrus Logic CS3308 audio analog-to-digital converters.

    • Networking: Netronome NFP4000/NFP6000 VF interfaces, Analog Devices ADF7242 SPI 802.15.4 wireless controllers, Freescale data-path acceleration architecture frame manager devices, IBM VNIC virtual interfaces, and STMicroelectronics ST95HF NFC transceivers.

    • Pin control: Qualcomm MSM8996 pin controllers, Marvell PXA27x pin controllers, Broadcom NSP GPIO controllers, and Allwinner H3 pin controllers.

Changes visible to kernel developers include:

  • The follow_link() method in struct inode_operations has been replaced with:

        const char *(*get_link) (struct dentry *dentry, struct inode *inode,
        			     struct delayed_call *done);
    

    It differs from follow_link() (which was described in this article) by separating the dentry and inode arguments and, most importantly, being callable in the RCU-walk mode. In that case, dentry will be null, and get_link() is not allowed to block.

    Also added in the same patch set was a "poor man's closures" mechanism, represented by struct delayed_call:

        struct delayed_call {
    	void (*fn)(void *);
    	void *arg;
        };
    

    See include/linux/delayed_call.h for the (tiny) full interface. In this case, get_link() should set done->fn to its inode destructor function — probably the one that was previously made available as the (now removed) put_link() inode_operations method.

  • There is a new memory-barrier primitive:

        void smp_cond_acquire(condition);
    

    It will spin until condition evaluates to a non-zero value, then insert a read barrier.

  • There is a new stall detector for workqueues; if any workqueue fails to make progress for 30 seconds, the kernel will output a bunch of information that should help in debugging of problem.

  • There is a new helper function:

        void *memdup_user_nul(const void __user *src, size_t len);
    

    It will copy len bytes from user space, starting at src, allocating memory for the result and adding a null-terminating byte. Over 50 call sites have already shown up in the kernel.

  • The configfs virtual filesystem now supports binary attributes; see the documentation changes at the beginning of this commit for details.

  • Changes to the networking core mean that NAPI network drivers get busy polling for free, without the need to add explicit support.

  • Patches moving toward the removal of protocol-specific checksumming from networking drivers (described in this article) have been merged. See this merge commit for more information.

The 4.5 merge window will probably stay open until January 24, so there is time for a lot more changes to find their way into the mainline. As usual, LWN will track those changes and summarize them in the coming weeks; stay tuned.

Index entries for this article
KernelReleases/4.5


to post comments

The 4.5 merge window opens

Posted Jan 14, 2016 7:51 UTC (Thu) by kugel (subscriber, #70540) [Link] (1 responses)

I still don't understand why copy_file_range() functionality wasn't simply added to splice()

The 4.5 merge window opens

Posted Jan 14, 2016 18:34 UTC (Thu) by billygout (guest, #70918) [Link]

Just a guess: They want to preserve the splice()'s EINVAL return value when neither file is a pipe, in order to avoid "breaking" user space in the case that user space is relying on the error?

The 4.5 merge window opens

Posted Jan 14, 2016 15:42 UTC (Thu) by tshow (subscriber, #6411) [Link] (4 responses)

I'm always vaguely surprised these merge window summaries don't seem to mention GPU support updates.

The 4.5 merge window opens

Posted Jan 14, 2016 15:45 UTC (Thu) by corbet (editor, #1) [Link] (3 responses)

I can't get into the improvements in any device driver; would have to buy a bigger disk for the server. I do try to mention significant things, like the amdgpu driver that went in a few cycles ago.

In this particular case, no GPU-related trees had been pulled by the time I wrapped that article up.

Is there something in particular that you think was missing?

The 4.5 merge window opens

Posted Jan 14, 2016 16:44 UTC (Thu) by tshow (subscriber, #6411) [Link] (2 responses)

> Is there something in particular that you think was missing?

Not as such; my focus is game dev, though, so a lot of my interest is in the state of the graphics stack.

The 4.5 merge window opens

Posted Jan 14, 2016 16:56 UTC (Thu) by SEJeff (guest, #51588) [Link]

You might also consider looking at the kernel newbies LinuxChanges page when this kernel is released for the gory details.

GPU updates in 4.5

Posted Jan 16, 2016 5:15 UTC (Sat) by pr1268 (subscriber, #24648) [Link]

Wouldn't most of the GPU updates for which you're interested in happen in user space?

The only "blockbuster" GPU feature I've seen happen in the Kernel in recent memory is DRI modesetting. Besides specific GPU chipset drivers, that is.

My intuition tells me that the the remainder of the Kernel's GPU code (DRM / DRI / PCIe / bus architecture, moving video buffers around in memory, etc.) has stayed current with technology the past few years.

The 4.5 merge window opens

Posted Jan 14, 2016 23:39 UTC (Thu) by gerdesj (subscriber, #5446) [Link] (2 responses)

"The SOCK_DESTROY operation"

New? My big toes have been performing that operation for decades.

SOCK_DESTROY

Posted Jan 16, 2016 11:54 UTC (Sat) by robbe (guest, #16131) [Link] (1 responses)

But now your Linux-running shoe (not Linux running-shoe, mind you!) can do it for you.

BTW,
toe nail | cut | file
in a cronjob may help with your problem.

SOCK_DESTROY

Posted Jan 16, 2016 22:52 UTC (Sat) by gerdesj (subscriber, #5446) [Link]

robbe, I had a good giggle over "toe nail | cut | file" I have been a Unix, via Linux, aficionado for around 17 years and have never come across the toe command before - thank you.

I may be off course but I suspect that English might be a second language for you. There's generally no need to point out which of two interpretations is correct in an ambiguous sentence. However the preceding rule can be broken for comic effect and an exclamation mark casually dropped in front of a bracket could be a hint that I'm way off course.

Anyway, we need to come up with a command that parses in /bin/sh and nail doesn't cut it.


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