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

[Martin KaFai Lau <martin.lau@linux.dev>]

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.

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.