[$] Concurrency management in BPF

In the beginning, programs run on the in-kernel BPF virtual machine had nopersistent internal state and no data that was shared with any other partof the system. The arrival of eBPF and, in particular, its mapsfunctionality, has changed that situation, though, since a map can beshared between two or more BPF programs as well as with processes runningin user space. That sharing naturally leads to concurrency problems, sothe BPF developers have found themselves needing to addprimitives to manage concurrency (the "exchange and add" or XADDinstruction, for example). The next step is the addition of aspinlock mechanism to protect data structures, which has also led to some wider discussions on what theBPF memory model should look like.