Kernel development

Kernel release status

The 4.10 kernel was released on February 19; in the announcement Linus said: "On the whole, 4.10 didn't end up as small as it initially looked. After the huge release that was 4.9, I expected things to be pretty quiet, but it ended up very much a fairly average release by modern kernel standards." Features of note in this release include some long-awaited writeback throttling work, the ability to attach a BPF network filter to a control group, encryption in UBIFS filesystems, Intel cache-allocation technology support, and more. See the KernelNewbies 4.10 page for lots of details.

Stable updates: 4.9.11 and 4.4.50 were released on February 18. The 4.9.12 and 4.4.51 updates can be expected on or after February 23.

Comments (1 posted)

Quotes of the week

— Casey Schaufler

— Tom Herbert

Comments (none posted)

The return of the Linux kernel podcast

After taking a few years off, Jon Masters is restarting his kernel podcast. "In this week’s edition: Linus Torvalds announces Linux 4.10, Alan Tull updates his FPGA manager framework, and Intel’s latest 5-level paging patch series is posted for review. We will have this, and a summary of ongoing development in the first of the newly revived Linux Kernel Podcast."

Comments (3 posted)

The 4.11 merge window opens

As of this writing, just over 4,400 non-merge changesets have been pulled into the mainline repository since the 4.10 release. The 4.11 merge window is, thus, off and rolling, though experience says that there is a lot of work that needs to be merged still. Some of the more interesting user-visible changes merged so far include:

• Work has resumed on the long-stalled perf ftrace work, which seeks to create a perf-based interface to the ftrace tracing subsystem. There will be a simple perf ftrace command in 4.11, with more to come in subsequent development cycles.

• The TIMER_STATS feature, which made some timer statistics available in /proc/timer_stats, has been removed. It was seen as a security problem, since it could leak process information across namespaces; the tracing subsystem should be used to get this information instead.

• The ext4 filesystem supports a new ioctl() command called EXT4_IOC_SHUTDOWN. It indicates that a volume is being destroyed and that there is no need to flush any data remaining in memory. This feature mirrors the existing XFS XFS_IOC_GOINGDOWN command; future work will probably promote it to the virtual filesystem layer with a name like FS_IOC_SHUTDOWN.

• The CIFS filesystem now supports SMB3 per-share encryption.

• The multiqueue block layer finally has support for I/O scheduling. That is useful in its own right, but the real news is that it enables the merging of the long-awaited BFQ I/O scheduler. That, says block maintainer Jens Axboe, "should be ready for 4.12".

• The block layer has also gained support for the Opal storage specification, providing a mechanism for the encryption of stored data.

• The device-mapper RAID 4/5/6 implementation has gained support for journaling, closing the "write hole" that could cause data loss in a badly timed crash.

• The new virtual file /sys/kernel/security/lsm can be read to see which security modules are active on the system.

• There is a new "SMC-R" socket type intended for communication over an RDMA transport. Alas, this feature would appear to be entirely undocumented in the kernel. Some information can seemingly be found in RFC 7609 and this slide deck [PDF].

• The new "psample" module allows for the sampling of packets passing through an interface, possibly filtered with a classifier.

• New hardware support includes:
  • Media: SPI-connected infrared LEDs, Mediatek IR remote receivers, NXP i.MX6 video data order adapters, Toshiba ET8EK8 5MP camera sensors, ZyDAS ZD1301 demodulators, and STMicroelectronics DELTA multi-format video decoders.

  • Miscellaneous: Aspeed AST2500 and AST2400 static memory controllers, Intel PCH/PCU SPI flash controllers, ST Microelectronics STTS751 temperature sensors, Maxim MAX14656 USB charger detectors, X-Powers AXP20X and AXP22X AC power supplies, Renesas OSTM timers, Qualcomm interrupt combiners, Motorola CPCAP PMIC voltage regulators, Lantiq SSC SPI controllers, Synopsys DW memory card interfaces, ZyDAS ZD1301 USB interfaces, Atari Falcon PATA controllers, aQuantia AQC107/AQC108-based network interfaces, and Qualcomm Technologies L2-cache performance-monitoring units.

  • Pin control: TI IODelay pin controllers, Intel Gemini Lake pin and GPIO controllers, Allwinner H5 SoC pin controllers, and STMicroelectronics STM32H743 pin controllers.

Changes visible to kernel developers include:

• The user-space perf tools can now be built with the LLVM Clang compiler.

• There is a new type for the implementation of reference counters called refcount_t; its purpose is to facilitate defenses against reference-count overflows. In a nutshell, this API looks like:

      #include <linux/refcount.h>
  
      refcount_t count = REFCOUNT_INIT(initial_value);
  
      void refcount_set(refcount_t *r, unsigned int n);
      unsigned int refcount_read(const refcount_t *r);
      bool refcount_add_not_zero(unsigned int i, refcount_t *r);
      void refcount_add(unsigned int i, refcount_t *r);
      bool refcount_inc_not_zero(refcount_t *r);
      void refcount_inc(refcount_t *r);
      bool refcount_sub_and_test(unsigned int i, refcount_t *r);
      bool refcount_dec_and_test(refcount_t *r);
      void refcount_dec(refcount_t *r);
      bool refcount_dec_if_one(refcount_t *r);
      bool refcount_dec_not_one(refcount_t *r);
      bool refcount_dec_and_mutex_lock(refcount_t *r, struct mutex *lock);
      bool refcount_dec_and_lock(refcount_t *r, spinlock_t *lock);
  

  See this commit for the full interface and implementation. This type should be used instead of atomic_t for reference counters; expect a set of conversions of existing atomic_t reference-counting usage over the next development cycle or two.

• There are two new interfaces for working with the kref type: KREF_INIT() to initialize a kref, and kref_read() to read the embedded counter's value. The purpose here is to better hide the internals of this structure so that they can be changed to use the new refcount_t type.

• The PAX "structleak" GCC plugin has been ported to the mainline. This plugin will force the initialization of structures that are copied to user space in the hope of preventing information leaks.

• The kernel now has a SipHash implementation, providing hashing that should be both faster and more secure. See Documentation/siphash.txt for more information.

If the usual schedule holds, the 4.11 merge window will remain open through March 5, and the final 4.11 release can be expected at the end of April. As usual, LWN will continue to watch the patch stream and summarize the rest of the merge window in the coming weeks.

Comments (none posted)

Control-group thread mode

The transition to the version-2 control-group API has been underway for a few years now. Most resource controllers work with the new interface, but there is a notable exception in the form of the CPU controller, which has been stalled as a result of disagreements over thread-level control. A new proposal for a control-group "thread mode" has generated more disagreement but, maybe, some hope for a resolution as well.

When the control-group interface was reworked, two fundamental design decisions shaped the result in ways that are relevant to the CPU controller. Control groups would no longer be allowed to contain both processes and other groups; instead, control groups would be internal to the group hierarchy and processes would be placed only at the leaves. The new API also differs from the original in that it only allows entire processes to be placed within a group; if a process is multi-threaded, all of its threads must be in the same group. There are solid reasons for these decisions: for many controllers, it is difficult to define rational semantics when processes and groups are competing in the same parent group, and a number of resources (memory usage, for example) are not amenable to control at the thread level.

Some controllers, though, can work well in a more flexible mode; the CPU controller is at the top of that list. It makes sense for processes to compete with control groups for the CPU, and it is often desirable to apply different CPU-usage policies to different threads within the same process. The version-2 API make such configurations impossible, though, to the dismay of users who felt they had lost an important capability. Potential solutions to this problem have been under discussion for some time. A separate "resource groups" mechanism was proposed almost one year ago, for example, but it brought little satisfaction and did not get far.

Control-group maintainer Tejun Heo's latest attempt is called "thread mode". Rather than create a new "resource group" abstraction under application control, it extends the control-group mechanism to provide special groups at the leaves of the hierarchy. Consider, for example, a traditional control-group hierarchy that looks like this:

There are two control groups ("A" and "B") below the root group. The process P1 is contained within A, while P2 and P3 are inside B. This hierarchy follows the rules, since all processes are found at the leaves.

With the new thread mode, the administrator can designate any empty control group as being a "thread point". This group can then be populated with a hierarchy of "thread groups" below it. Thread groups look like regular control groups, but with some significant differences: they can contain both threads and other thread groups, and a single process's threads can be spread across multiple thread groups. A hierarchy using this feature might look like this:

The thread groups ("T1" and "T2") form their own hierarchy below B, which has been marked as a thread point. Note that T1 is able to contain both the thread group T2 and the process P3. In this example, the "processes" P2 and P3 could, in fact, be threads belonging to the same process.

Resource controllers that are not explicitly enabled for thread mode will never see the hierarchy above; instead, the thread groups will, from their point of view, be collapsed out of existence and the hierarchy will look as it did in the first diagram above. Controllers that are able to deal with the thread mode will see the entire hierarchy, though, and will be able to perform resource control at thread granularity.

Scheduler maintainer Peter Zijlstra, who has been an ongoing critic of the control-group changes, was not entirely pleased with this version either. In particular, he disliked the constraint that the thread groups can only appear at the bottom of the hierarchy. The use case he has in mind involves running a threaded workload directly out of the root group, resulting in a hierarchy looking something like this:

The main reason for running the workload in the root group would appear to be performance; there is a small cost to putting processes lower in the hierarchy. Zijlstra would still like to apply full resource control to other groups that might, for example, contain a virtual machine running some sort of secondary workload. Heo's current patch will not support this mode, though, since threaded groups cannot be contained within the same parent group as non-threaded groups.

That restriction exists because to do otherwise would be a violation of the "no internal processes" rule. For non-thread-capable controllers, the thread groups would vanish and the processes contained therein would appear to be contained in the parent — the root group in this case. That would bring back all of the problems that this rule was created to avoid.

There was some strongly worded back-and-forth over whether Zijlstra's use case was something that needed to be (or could be) supported but, in the end, both developers were clearly interested in working out a solution that satisfied the constraints. The form that solution will take is not entirely clear, but Heo outlined one possibility. When a threaded group would share the same parent group as a non-threaded group, the answer is to interpose another group. So, rather than putting T1 directly in the root group as shown above, it would be placed in a new group (call it "C"), and C would be located under the root. That moves the threaded group back out to a leaf, resolving the issues. The intermediate group could be hidden from administrators, but it would need to be there internally.

Zijlstra had actually wanted to make things even more flexible by allowing a threaded group to contain a non-threaded group — essentially doing the thread-point transition in reverse. That would complicate things even further and, in the absence of compelling use cases calling for it, that mode seems unlikely to be implemented.

The real proof will come with a subsequent version of the patch set. There will, undoubtedly, be further disagreements to be worked out. But it seems possible that this work might finally be on a path where it can get past the roadblocks that have kept it out of the mainline until now. That would be a welcome end to a project that has taken rather longer than anybody involved would have expected or wanted.

Comments (none posted)