What’s New in Linux Kernel 4.14 LTS “Fearless Coyote” – Key Features and Insights

In September, Linux kernel developer Greg Kroah‑Hartman confirmed on his blog that Linux 4.14 would be the next LTS kernel, initially slated for two‑year support but later extended to six years, resulting in an unusually long development cycle with eight release‑candidate (rc) versions.

Linus Torvalds announced the release of Linux 4.14 LTS, codenamed “Fearless Coyote”, noting that the shortlog since rc8 contains only a few small commits.

The release also mentions improvements to the 0‑day robot testing tool, which automatically scans kernel code for security vulnerabilities.

Main Features

The primary new feature is the integration of heterogeneous memory management into the mainline, allowing process address spaces to be mirrored and enabling transparent use of system memory by any device.

Another major change relaxes memory limits on x86_64 hardware, supporting larger memory capacities.

Vega improvements

Continued hardware support for Cannonlake

Support for Zstd compression

AMD secure memory encryption for EPYC server CPUs

New Realtek “rtlwifi” driver

Raspberry Pi gains HDMI‑CEC support

F2FS tuning for Android

Improvements to Btrfs, EXT4, and XFS

Rewritten Intel cache quality monitoring code

For a more comprehensive list of features, see the Phoronix article linked in the original post.

The source tarball for Linux 4.14 can be downloaded from kernel.org.

No surprises this week, although it is probably worth pointing out how the 0‑day robot has been getting even better (it was very useful before, but Fengguang has been working on making it even better, and reporting the problems it has found). Sure, some of the new reports turned out to be just 0‑day doing things that just don’t work (i.e., KASAN with old gcc versions, but also doing things like loading old ISA drivers in situations that just don’t make sense). The appended shortlog is obviously only for the (small) haul since rc8, and it really is tiny. Not very many commits, and they are small. The biggest thing that stands out in the diffstat is the "leaking_addresses" perl script, which is actually under active development, but I put the first version in for 4.14 just so that people could see that initial state and start looking at the end result and perhaps ask themselves "should my code make these kernel addresses visible to user space". The actual changes will hopefully start percolating into 4.15, with one notable early change being to hash any "%p" addresses by default. Previously we had strict modes that zeroed the address, which was counter‑productive for debugging uses that rely on the address as a kernel object identity. Other situations where the actual address is relevant will need different approaches, such as restricting /proc/kallsyms to entities that actually need them. The most noticeable last‑minute change is reverting code that showed a good MHz value in /proc/cpuinfo for dynamically scaling CPUs, as it was too expensive on machines with many cores. Overall, the rest of the changes are mostly one‑liners or few‑liners. Linus encourages testing the new 4.14 release, which is the upcoming LTS kernel, and to start sending pull requests for the 4.15 merge window. — Linus

Translation: This week there were no surprises, although it may be worth noting how the 0‑day robot has become better (it was very useful before, and Fengguang has been working to improve it and report the problems it finds). The appended shortlog clearly only covers the small set of changes since rc8, and it is indeed tiny, with few commits. The biggest item in the diffstat is the "leaking_addresses" perl script, now under active development; the first version was added to 4.14 so people can see the initial state and consider whether kernel addresses should be exposed to user space. Future changes are expected to flow into 4.15, including a notable early change to hash any "%p" addresses by default, replacing the previous strict mode that zeroed them, which hindered debugging that relied on address identity. Other cases where the actual address matters will require different solutions, such as limiting /proc/kallsyms access. The most obvious change is reverting code that displayed a good MHz value in /proc/cpuinfo for modern CPUs that dynamically pick frequencies, as it was too costly on machines with dozens or hundreds of cores. Overall, apart from that script, the remaining changes are essentially one‑liners or few‑liners. Test the new 4.14 release, the next LTS kernel, and start sending pull requests for the 4.15 merge window.