Re: [RFC bpf-next v1 2/4] bpf: Support cookie for linked-based struct_ops attachment

[Amery Hung <ameryhung@gmail.com>]

On Wed, Jul 9, 2025 at 3:13 PM Martin KaFai Lau <martin.lau@linux.dev> wrote:
>
> On 7/8/25 4:08 PM, Amery Hung wrote:
> > @@ -906,6 +904,10 @@ static long bpf_struct_ops_map_update_elem(struct bpf_map *map, void *key,
> >               goto unlock;
> >       }
> >
> > +     err = bpf_struct_ops_prepare_attach(st_map, 0);
>
> A follow-up on the "using the map->id as the cookie" comment in the cover
> letter. I meant to use the map->id here instead of 0. If the cookie is intended
> to identify a particular struct_ops instance (i.e., the struct_ops map), then
> map->id should be a good fit, and it is automatically generated by the kernel
> during the map creation. As a result, I suspect that most of the changes in
> patch 1 and patch 2 will not be needed.
>

Do you mean keep using cookie as the mechanism to associate programs,
but for struct_ops the cookie will be map->id (i.e.,
bpf_get_attah_cookie() in struct_ops will return map->id)?

> If I understand correctly, the kfunc implementation needs to look up the scx_ops
> instance (i.e., the struct_ops map) from the map->id/cookie. There is a similar
> map->id lookup in bpf_map_get_fd_by_id(), which requires acquiring a spin_lock.
> If performance is a concern, we can investigate whether it can be rcu-ified.
>  From a quick glance, bpf_map_free_id() is called before call_rcu(). Note that
> bpf_struct_ops_map_free() will wait for an RCU grace period.
>