Sleepable BPF programs

When support for classic BPF was added to the kernel many years ago, there was no question of whether BPF programs could block in their execution. Their functionality was limited to examining a packet's contents and deciding whether the packet should be forwarded or not; there was nothing such a program could do to block. Since then, BPF has changed a lot, but the assumption that BPF programs cannot sleep has been built deeply into the BPF machinery. More recently, classic BPF has been pushed aside by the extended BPF dialect; the wider applicability of extended BPF is now forcing a rethink of some basic assumptions.

当多年前内核首次引入对经典 BPF 的支持时，根本不存在 BPF 程序是否可以在执行过程中阻塞的问题。它们的功能仅限于检查数据包内容并决定是否转发该数据包；这样的程序没有任何可能阻塞的操作。自那以后，BPF 发生了巨大变化，但 BPF 程序不能睡眠的假设已深深嵌入 BPF 的机制中。最近，经典 BPF 已经被扩展 BPF 取代；扩展 BPF 更广泛的适用性正在迫使人们重新思考一些基本假设。

BPF programs can now do many things that were not possible for classic BPF programs, including calling helper functions in the kernel, accessing data structures ("maps") shared with the kernel or user space, and synchronizing with spinlocks. The core assumption that BPF programs are atomic has not changed, though. Once the kernel jumps into a BPF program, that program must complete without doing anything that might put the thread it is running in to sleep. BPF programs themselves have no way of invoking any sort of blocking action, and the helper functions exported to BPF programs by the ke