This change adds support for 32 bit kernels by capping mProducerPos to
4 bytes. mConsumerPos (which is written to by userspace) continues to
use 8 bytes. (This can be done because an entire page is allocated for
mConsumerPos to control access permissions). In a 32 bit kernel, that
means that the top order bits are just ignored. In addition, comparisons
in userspace only use the bottom 4 bytes to be bitness agnostic.
Test: atest BpfRingbufTest
Change-Id: I7fe6d9000a151512785f1aa2a53fa97d31967d19
Both consumer and producer position are wrapped in an std::atomic and
extended to uint64_t to enforce atomic access.
See resulting assembly instructions for aosp_cf_x86_phone-userdebug:
frameworks/libs/net/common/native/bpf_headers/include/bpf/BpfRingbuf.h:212
2d: 8b 41 18 mov 0x18(%ecx),%eax
external/libcxx/include/atomic:926 (discriminator 4)
30: f3 0f 7e 00 movq (%eax),%xmm0
This will not work on a 32 bit kernel (so we might want to explicitly
check for that in the test).
Test: atest BpfRingbufTest
Change-Id: I7fec435cbe49d392363d05f7e702d82ecacb9e91
This implements the bare minimum to read from BPF ring buffers in
userspace. The implementation uses two shared memory regions with
atomic-like access. Currently, the class only guarantees that the
element type has the same size (later can add btf support).
The alternative would be to use libbpf or bcc, but since this is a small
header-only library that seemed like it could end up being more
difficulty than it was worth.
Bug: 246985031
Test: atest libbpf_android_test
Change-Id: I7f08e76db9cb9672ef66c629bccb3db63d3c2229
This adds a BPF program with a ring buffer and an associated test that
ensures the program and ring buffer can be loaded by the bpf loader. In
the following changes, this foundation will be used to test the user
space ring buffer wrapper class.
Unlike BpfMap, userspace can't (easily) write to the ring buffer so the
most accurate way to test a userspace ring buffer implementation is to
write to it from a BPF program.
Note: the BPF program in this change is never actually attached to a
cgroup, it is only loaded. The program will be executed manually using
BPF_PROG_RUN which is "side-effect free" (it can have side effects on
BPF maps, but not on Kernel state, e.g. dropping packets).
Bug: 246985031
Test: atest libbpf_android_test
Change-Id: Ib9c591218188f5f358a755c8854bc6f87d26af12
