On Wed, Oct 12, 2022 at 11:24 PM Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx> wrote: > > From: Dave Marchevsky <davemarchevsky@xxxxxx> > > Currently libbpf does not allow declaration of a struct bpf_spin_lock in > global scope. Attempting to do so results in "failed to re-mmap" error, > as .bss arraymap containing spinlock is not allowed to be mmap'd. > > This patch adds support for a .bss.private section. The maps contained > in this section will not be mmaped into userspace by libbpf, nor will > they be exposed via bpftool-generated skeleton. > > Intent here is to allow more natural programming pattern for > global-scope spinlocks which will be used by rbtree locking mechanism in > further patches in this series. > > Notes: > > * Initially I called the section .bss.no_mmap, but the broader > 'private' term better indicates that skeleton shouldn't expose these > maps at all, IMO. > > * bpftool/gen.c's is_internal_mmapable_map function checks whether the > map flags have BPF_F_MMAPABLE, so no bpftool changes were necessary > to remove .bss.private maps from skeleton > > Signed-off-by: Dave Marchevsky <davemarchevsky@xxxxxx> > Signed-off-by: Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx> > --- Please see [0] for what I think is a better way forward specifically for the libbpf-side part. [0] https://patchwork.kernel.org/project/netdevbpf/list/?series=686066&state=* > tools/lib/bpf/libbpf.c | 65 ++++++++++++++++++++++++++++-------------- > 1 file changed, 44 insertions(+), 21 deletions(-) > [...]
