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>