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.
