This implements the userspace binding for RingBuf.
Instead of streaming the samples as heap buffers, the process_ring
function takes a callback to which we pass the event's byte region,
roughly following [libbpf]'s API design. This avoids a copy and allows
marking the consumer pointer in a timely manner.
[libbpf]: https://github.com/libbpf/libbpf/blob/master/src/ringbuf.c
Additionally, integration tests are added to demonstrate the usage
of the new APIs and to ensure that they work end-to-end.
Co-authored-by: William Findlay <william@williamfindlay.com>
Co-authored-by: Tatsuyuki Ishi <ishitatsuyuki@gmail.com>
The implementation changed since the original commit was written, and
some mistakes went in:
- missing bpf_redirect_map wrapper
- extra bpf_map_lookup_elem on maps for which it is forbidden
The bpf_map_defs are now wrapped with UnsafeCell, which also happens to
provide a cozy way to get a *mut pointer. An UnsafeCell isn't strictly
required as the struct fields are practically opaque to us, but using an
UnsafeCell follows the general best practices against miscompilation and
also prevents some obvious errors.
HashMap::get_mut was removed because the idea is completely unsound.
Previous users should wrap their data with UnsafeCell instead or use
atomics.
Closes: https://github.com/aya-rs/aya/issues/233
Currently BPF_MAP_TYPE_STACK is supported by user code (`aya/src/maps/stack.rs`),
but it does not support the BPF_MAP_TYPE_STACK BPF code.
This patch fixes it.
Map lookup and deletion can yield stale keys and values by virtue of
sharing a data structure with userspace programs and other BPF programs
which can modify it. However, all accesses remain perfectly safe and will
not cause memory corruption or data races.
This is necessary since the context is used in many other program types
and not just in SK_SKB programs.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
The type casting introduces an allocation, this will cause compiling failure when linking final bpf target.
So remove this casting to fix this issue.
BTW, the following is the failure I met:
= note: 07:24:12 [ERROR] fatal error: "unable to allocate function return #1"
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0. Running pass 'Function Pass Manager' on module 'trace_bpf-001a275b17e9eb12'.
1. Running pass 'BPF DAG->DAG Pattern Instruction Selection' on function '@_ZN7aya_bpf4maps11stack_trace10StackTrace11get_stackid17h32b649bc3780c0aaE'
Signed-off-by: Tw <wei.tan@intel.com>