Hi Andrii, > But before we make any changes, can you please share a reproducer for > this issue? And which architecture (x86-64? arm64?) did you manage to > reproduce this issue on? I have uploaded an reproducer here: https://github.com/ishitatsuyuki/bpf-ringbuf-examples First, I only modified the ringbuf-output sample, so please go into src and do `make ringbuf-output`. Second, it turned out that libbpf was actually immune to the issue due to it using epoll in the level-triggered mode. Presumably, epoll first does some internal locking which acts as a global memory barrier, then it proceeds on checking the ringbuf pointers again, which effectively prevent the anomalies. When ET is used, epoll instead waits for the wakeup without double checking the ringbuf pointers, allowing the anomaly to happen. In the reproducer above, I've modified the libbpf submodule to use EPOLLET, so that it does reproduce the phenomenon I was talking about, but this also means that this is not an issue with libbpf per se. Still, relying on the implicit synchronization of epoll is rather ugly, and can cause confusion when trying to re-implement the logic using libbpf as the reference. The reproducer should get "stuck" in a few seconds when running on x86-64; I don't have an AArch64 machine to test on, but as far as I understand the acq/rel instructions gets promoted to seq_cst on those, so this issue simply cannot surface on AArch64. Tatsuyuki
