[$] Concurrency management in BPF

In the beginning, programs run on the in-kernel BPF virtual machine had no
persistent internal state and no data that was shared with any other part
of the system. The arrival of eBPF and, in particular, its maps
functionality, has changed that situation, though, since a map can be
shared between two or more BPF programs as well as with processes running
in user space. That sharing naturally leads to concurrency problems, so
the BPF developers have found themselves needing to add
primitives to manage concurrency (the 'exchange and add' or XADD
instruction, for example). The next step is the addition of a
spinlock mechanism to protect
data structures, which has also led to some wider discussions on what the
BPF memory
model should look like.