On Sat, 10 Sept 2022 at 00:57, Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Fri, Sep 9, 2022 at 3:50 PM Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx> wrote: > > > > So compared to the example above, user will just do: > > struct bpf_spin_lock lock1; > > struct bpf_spin_lock lock2; > > struct bpf_list_head head __contains(...) __guarded_by(lock1); > > struct bpf_list_head head2 __contains(...) __guarded_by(lock2); > > struct bpf_rb_root root __contains(...) __guarded_by(lock2); > > > > It looks much cleaner to me from a user perspective. Just define what > > protects what, which also doubles as great documentation. > > Unfortunately that doesn't work. > > We cannot magically exclude the locks from global data > because of skel/mmap requirements. > We cannot move the locks automatically, because it involves > massive analysis of the code and fixing all offsets in libbpf. > So users have to use a different section when using > global locks, rb_root, list_head. > Since a different section is needed anyway, it's better to keep > one-lock-per-map-value for now. Argh, right. Then they need one extra 'annotation', at that point it's a bit questionable. Also just realized reading your other reply that there are also unanswered questions wrt what we do for BPF_F_LOCK.
