[BPF TOPIC] BPF Memory Model

[BPF TOPIC] BPF Memory Model

[Paul E. McKenney]

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.