|
|
Subscribe / Log in / New account

3.16 merge window, part 2

By Jake Edge
June 11, 2014

This is the second installment of our coverage of the 3.16 merge window. See last week's article for a rundown of what happened in the first few days of the window. Since then, Linus Torvalds has returned to the master branch of his repository after merging back 6800 or so non-merge commits from his next branch. At this point, he has merged 8179 patches for 3.16, which is 2831 since last week's article.

Here are some of the larger changes visible to users:

  • Hugepage migration has been turned off for all architectures except x86_64 since it is only tested on that architecture and there are bugs for some of the others. It can be enabled for other architectures when they are ready to support it.
  • Automatic NUMA balancing has been turned off for 32-bit x86. Existing 32-bit NUMA systems are not well supported by the code and the developers did not think the effort to support them would be worthwhile.
  • The kernel memory control group (kmemcg) has been marked in the documentation and Kconfig as "unusable in real life so DO NOT SELECT IT unless for development purposes".
  • 16-bit stack segments will be allowed on 64-bit x86 kernels again. That feature was disabled due to a kernel information leak of the top 16 bits of the stack pointer that has now been fixed. Users will regain the ability to run 16-bit Windows programs in Wine on 64-bit kernels.
  • The kernel EFI code will now handle Unicode characters. It has also been changed to save and restore the floating point registers around EFI calls since EFI firmware may use the FPU.
  • EFI stub support for ARM64 (aarch64) has been added.
  • The ARM architecture has gained hibernation support. It has also made Ftrace work with read-only text in modules. In addition, the architecture improved its stack trace support by excluding the stack-trace functions from the trace and by allowing kprobes to record stack traces.
  • The remap_file_pages() system call has been marked as deprecated. The replacement that emulates the semantics but will run more slowly has not been submitted for merging yet.
  • The control group (cgroup) hierarchy handling has been reworked to provide a single unified hierarchy. Its use is governed by the __DEVEL__sane_behavior mount option. See our article further down and the new Documentation/cgroups/unified-hierarchy.txt for more information.
  • Neil Brown's patches to make loopback NFS mounts work reliably have been merged through the NFS tree. The other parts of his fixes are coming via other trees.
  • The external data representation (XDR) handling in NFS has been reworked to support access control lists (ACLs) larger than 4KB. It also returns readdir() results in chunks larger than 4KB giving better performance on large directories.
  • The PowerPC 64-bit little-endian kernel now supports the ELFv2 ABI. There is also a new 64-bit little-endian boot wrapper for PowerPC.
  • New hardware support:
    • Clocks: APM X-Gene real-time clocks (RTCs); MicroCrystal RV4162 RTCs; Dallas/Maxim DS1343 and DS1344 RTCs; Microchip MCP795 RTCs; Dialog Semiconductor DA9063 RTCs; Orion5x SoC clocks; and S2MPS11/S2MPS14/S5M8767 crystal oscillator clocks.
    • Miscellaneous: Renesas VMSA-compatible IPMMUs (IOMMUs); Realtek RTS5129/39 series USB SD/MMC card readers; Memstick card interface for Realtek RTS5129/39 series USB card readers; X-Powers AXP202 and AXP209 power management units (PMUs); PRCM (Power/Reset/Clock Management) units for Allwinner A31 SoCs; Atmel Microcontrollers found on the iPAQ h3xxx series to handle some keys, the touchscreen, and battery monitoring; ChromeOS EC (embedded controller) i2c command tunneling; Marvell EBU SoC onboard AHCI SATA controllers; MOXART SD/MMC host controllers; Allwinner sunxi SD/MMC host controllers; Renesas USDHI6ROL0 SD/SDIO host controllers; Dell SMO8800/SMO8810 freefall sensors; IBM Akebono (476gtr) evaluation boards; Keymile's kmcoge4 boards; OCA4080 boards; T1040 and T1042 QDS boards; Freescale BSC9132 QDS boards; and Intel MID platform watchdog timers.
    • Video: DTCS033 (Scopium) USB Astro-Cameras; Silicon Labs Si2157 tuners; Silicon Labs Si2168 DVB-T/T2/C demods; Broadcom Set Top Box Level 2 interrupt controllers; and Xilinx AXI Video DMA (VDMA) engines.

Kernel developers will see the following changes:

  • Flattened device tree (FDT) parsing has been converted to use libfdt. Knowledge of FDT internals has also been removed from most architectures except PowerPC.
  • Videobuf2 now supports the Digital Video Broadcasting (DVB) standard.
  • The 32-bit only setup_sched_clock() has been removed. Calls to it have been converted to sched_clock_register().
  • The create_irq() and destroy_irq() interface (and its variants) for handling sparse IRQ allocation has been removed. As Thomas Gleixner put it: "get rid of the horrible create_irq interface along with its even more horrible variants".
  • The ARM level 2 cache support has been cleaned up, which results in a "much nicer structure" and some performance improvements, according to Russell King in his pull request.
  • ARM64 (aarch64) has added some optimized assembly for string and memory routines as well as for cryptography algorithms (SHA family, AES, GHASH). It has also added Ftrace support.
  • A tracepoint benchmarking facility has been added to the kernel tracing subsystem.
  • Some tracers (latency, wakeup, wakeup_rt, irqsoff, preemptoff, preemptirqsoff) can now be used in separate tracing instances, though only one instance can use each tracer at any given time. Also, the function and function graph tracers can be used together.
  • As part of the fix for CVE-2014-4014, the inode_capable() function has been renamed to capable_wrt_inode_uidgid() to better reflect what it does.
  • A decode_stacktrace.sh script has been added to turn offsets from symbols into filenames and line numbers to make it easier to read.

We should be most of the way through the merge window at this point, but there may still be merges of interest in the next few days. Stay tuned for next week's thrilling conclusion ...

Index entries for this article
KernelReleases/3.16


to post comments

3.16 merge window, part 2

Posted Jun 12, 2014 5:49 UTC (Thu) by luto (subscriber, #39314) [Link] (1 responses)

The capable_wrt_inode_uidgid change was the entire fix for CVE-2014-4014. No one as claimed the prize for figuring out the vulnerability yet :)

3.16 merge window, part 2

Posted Jun 13, 2014 7:30 UTC (Fri) by rvfh (guest, #31018) [Link]

inode_owner_or_capable() was also modified to support the case where 'current [...] has CAP_FOWNER in a namespace with the inode owner uid mapped'.

3.16 merge window, part 2

Posted Jun 27, 2014 10:14 UTC (Fri) by eru (subscriber, #2753) [Link] (4 responses)

  • 16-bit stack segments will be allowed on 64-bit x86 kernels again. That feature was disabled due to a kernel information leak of the top 16 bits of the stack pointer that has now been fixed. Users will regain the ability to run 16-bit Windows programs in Wine on 64-bit kernels.

Didn't even know that was ever possible, but could be useful for my purposes. I wonder where I can find docs on how to allocate actual x86 16-bit segments, or for that matter 32-bit segments from user code? Manpages and googling turned up nothing.

3.16 merge window, part 2

Posted Jun 27, 2014 16:27 UTC (Fri) by khim (subscriber, #9252) [Link] (3 responses)

What have you tried to find in Google? Request How to modify LDT in Linux returns the appropriate manpage as the first hit!

3.16 merge window, part 2

Posted Jun 28, 2014 10:12 UTC (Sat) by eru (subscriber, #2753) [Link] (2 responses)

Thanks, khim. I guess I was too dense to include "ldt" in my queries. The manpage is not too informative, though. It does not say if I can extend the LDT with the call, and a quick test on my home x86_64 machine just returned 0 as the size, when reading the LDT (maybe this works only in 32-bit processes?). I would like to be able to allocate at least about ten LDT entries, in order to partially simulate a legacy system, where code, data and stack are all in different segments, and memory allocation calls return fresh segments with their own LDT entries.

Oh well, I probably have to read relevant bit of the kernel source for further investigations.

3.16 merge window, part 2

Posted Jun 28, 2014 12:43 UTC (Sat) by khim (subscriber, #9252) [Link] (1 responses)

LDT is unusable in 64bit mode, yes. This is hardware limitation. It's fully usable in 32bit process even on x86-64 system with 64bit kernel. For 32bit process there are examples (e.g. you could look on NaCl here).

3.16 merge window, part 2

Posted Jun 29, 2014 12:11 UTC (Sun) by eru (subscriber, #2753) [Link]

Thanks again, I will study that sample.


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