4.5 merge window part 3

• A new tool called UBSAN checks a running kernel for various types of undefined behavior that can lead to obscure bugs; the commit changelog contains a list of bugs that have already been found by UBSAN and fixed. See Documentation/ubsan.txt for an introduction to this tool.

• The new CONFIG_IO_STRICT_DEVMEM option, which blocks access to memory (via /dev/mem) claimed by device drivers, turned out to break booting on some systems, so it is now off by default.

• The ARM multiplatform work, which aims to build a single ARM kernel that can boot on a wide variety of processors, has reached an important milestone with the merging of work to bring a number of minor platforms into the fold.
  This branch is the culmination of 5 years of effort to bring the ARMv6 and ARMv7 platforms together such that they can all be enabled and boot the same kernel. It has been a tremendous amount of cleanup and refactoring by a huge number of people, and creation of several new (and major) subsystems to better abstract out all the platform details in an appropriate manner.

• The filesystems in user space (FUSE) subsystem has added support for the SEEK_HOLE and SEEK_DATA options to the lseek() system call.

• The epoll_ctl() system call supports a new flag, EPOLLEXCLUSIVE, that causes epoll_wait() to only wake one process when a file descriptor becomes ready. See this article for a description of this option and the use case for it.

• Direct-access ("DAX") mappings now work properly with the msync() and fsync() system calls.

• The ext4 filesystem has gained "project quota" support, wherein dispersed files can be assigned to the same "project" and given their own quota. The feature is rigorously undocumented, but some information be found in the header of this patch posting.

• The implementation of the XFS XFS_IOC_FSSETXATTR and XFS_IOC_FSGETXATTR ioctl() commands has been moved up to the virtual filesystem level, and an implementation for the ext4 filesystem has been added. This operation, also severely undocumented, allows the querying (and setting) of various file attributes, including immutability, whether writes should always be synchronous, exclusion from backups, and more. See the defines near the top of this commit for the list of supported attributes.

• The Ceph filesystem now has support for asynchronous I/O.

• New hardware support includes:
  • Systems and processors: Renesas R-Car H3 systems, Ralink MT7621 processors, Microchip PIC32MZDA processors, Socionext UniPhier systems, and NVIDIA Tegra132 processors.

  • Miscellaneous: Qualcomm "shared memory state machine" controllers, Qualcomm wireless connectivity subsystem controllers, Qualcomm PCIe controllers, TI AMx3 Wkup-M3 inter-processor communication subsystems, Raspberry Pi power domain controllers, TI OMAP dual-mode timers, HiSilicon Hip06 PCIe host controllers, Intel "volume management device" PCI host bridges, and AMD "non-transparent bridge" performance-monitoring hardware.

Finally, back in December, Linus noticed that the user-space access utilities (get_user() and friends) were showing up heavily on some profiles, especially on systems where supervisor-mode access prevention is in use. The problem is that, often, the kernel needs to perform several accesses in a sequence, with the result that access prevention is turned off and back on numerous times.

The solution, as is so often the case, is batching: turn off access prevention once, do all the work, then turn it back on. To support this mode of access, Linus has introduced a new set of macros:

    user_access_begin();
    unsafe_put_user(value, user_space_pointer);
    unsafe_get_user(value, user_space_pointer);
    user_access_end();

As he puts it in the comments, the "unsafe" functions are not actually unsafe if they are used correctly, but developers must pay attention. The unsafe_put_user() and unsafe_get_user() macros can only be used after a user_access_begin() call is made, and the usual access_ok() checks must be done first. The first use of these functions is in the user-space string-manipulation functions. Only x86 is supported in 4.5, but support for other architectures should be forthcoming.

At the close of the merge window, 10,305 non-merge changesets had been pulled into the mainline repository. That suggests that 4.5 will be a relatively slow development cycle with regard to the number of changes merged. Much of that "slowness" can be attributed to a relatively small merge from the staging tree this time around; otherwise, the kernel developers appear to be working at full speed.

If the usual 63-day cycle holds, the release of the final 4.5 kernel can be expected to happen on March 13. Between now and then, though, there are certainly numerous bugs to be found and fixed.