BPF Memory Model ================ Now that BPF supports concurrency, the issue of memory ordering is with us. This issue will become more pressing as additional atomic operations are added to BPF for the following reasons: 1. Developers will need to know how much synchronization is needed to make their concurrent BPF code work properly, regardless of the underlying hardware and compiler. 2. A BPF memory model can be helpful in locating concurrency bugs and checking fixes. Given that BPF interacts with the Linux kernel, the obvious candidate for the BPF memory model is of course the Linux-kernel memory model (LKMM). However, BPF will likely adopt atomic operations on an as-needed basis, and these will need to interact not only with each other, but also with in-kernel atomic operations. In addition, LKMM relies on help from coding conventions and compiler options, so some care is required to even exactly mimic LKMM. Some areas needing attention: a. Determining what in-kernel data should be accessed directly by BPF programs as opposed to accessed via helpers. For example, in-kernel data with complex access protocols might require access via helpers that enforce those protocols. b. Deciding what types of verification should be applied to BPF programs and at what point in the process. c. Deciding to what extent BPF verification should be integrated with in-kernel validation such as lockdep and KASAN. d. Adapting LKMM tooling to BPF programs. e. Working out which atomic operations to add to BPF and in which order. Tackling these issues head-on will help BPF move to concurrency with minimal shared-variable drama. This talk will summarize the current state and hopefully kick of discussions leading to improved approaches to BPF's sharing variables both within BPF and with the kernel.
