Sep 20 – 24, 2021
US/Pacific timezone

The never-ending saga of control dependencies

Sep 24, 2021, 8:50 AM
Microconference1/Virtual-Room (LPC Virtual)


LPC Virtual

Toolchains and Kernel MC Toolchains and Kernel MC


Will Deacon Peter Zijlstra (Intel OTC) Paul McKenney (Facebook) Jade Alglave (Arm)


The Linux kernel continues to rely on control dependencies as a cheap mechanism
to enforce ordering between a prior load and a later store on some of its
hottest code paths. However, optimisations by both the compiler and the CPU
hardware can potentially defeat this ordering and introduce subtle,
undebuggable failures which may only manifest on some systems.

Improving the robustness of control dependencies is therefore a hotly debated
topic, with proposals ranging from limiting their usage, inserting conditional
branches, introducing compiler support and using memory barriers instead. The
scope of possible solutions has resulted in somewhat of a deadlock, so this
session aims to cover the following in the interest of progressing the debate
and soliciting opinions from others:

  • What are control dependencies?
  • How can they be broken by the compiler?
  • How can they be broken by the CPU? (specifically, arm64)
  • volatile_if() and a potential compiler __builtin
  • A better barrier() macro
  • Upgrading READ_ONCE() and relaxed atomics to have acquire semantics

LKML mega-thread:

I agree to abide by the anti-harassment policy I agree

Primary authors

Will Deacon Peter Zijlstra (Intel OTC) Paul McKenney (Facebook) Jade Alglave (Arm)

Presentation materials

Diamond Sponsor

Platinum Sponsor

Gold Sponsors

Silver Sponsors

Speaker Gift Sponsor

T-Shirt Sponsor

Conference Services provided by