On Fri, Sep 9, 2022 at 3:30 PM Dave Marchevsky <davemarchevsky@xxxxxx> wrote:
> >
> > ".lock" won't work. We need lock+rb_root or lock+list_head to be
> > in the same section.
> > It should be up to user to name that section with something meaningful.
> > Ideally something like this should be supported:
> > SEC("enqueue") struct bpf_spin_lock enqueue_lock;
> > SEC("enqueue") struct bpf_list_head enqueue_head __contains(foo, node);
> > SEC("dequeue") struct bpf_spin_lock dequeue_lock;
> > SEC("dequeue") struct bpf_list_head dequeue_head __contains(foo, node);
> >
>
> Isn't the "head and lock must be in same section / map_value" desired, or just
> a consequence of this implementation? I don't see why it's desirable from user
> perspective. Seems to have same problem as rbtree RFCv1's rbtree_map struct
> creating its own bpf_spin_lock, namely not providing a way for multiple
> datastructures to share same lock in a way that makes sense to the verifier for
> enforcement.
The requirement to have only one lock in an "allocation"
(which is map value or one global section) comes from the need
to take that lock when doing map updates.
Shared lists/rbtree might require the verifier to take that lock too.
We can improve things with __guarded_by() tags in the future,
but I prefer to start with simple one-lock-per-map-value.
