On 7/10/25 11:39 AM, Amery Hung 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)?
I meant to use the map->id as the bpf_cookie stored in the bpf_tramp_run_ctx.
Then there is no need for user space to generate a unique cookie during
link_create. The kernel has already generated a unique ID in the map->id. The
map->id is available during the bpf_struct_ops_map_update_elem(). Then there is
also no need to distinguish between SEC(".struct_ops") vs
SEC(".struct_ops.link"). Most of the patch 1 and patch 2 will not be needed.
A minor detail: note that the same struct ops program can be used in different
trampolines. Thus, to be specific, the bpf cookie is stored in the trampoline.
If the question is about bpf global variable vs bpf cookie, yeah, I think using
a bpf global variable should also work. The global variable can be initialized
before libbpf's bpf_map__attach_struct_ops(). At that time, the map->id should
be known already. I don't have a strong opinion on reusing the bpf cookie in the
struct ops trampoline. No one is using it now, so it is available to be used.
Exposing BPF_FUNC_get_attach_cookie for struct ops programs is pretty cheap
also. Using bpf cookie to allow the struct ops program to tell which struct_ops
map is calling it seems to fit well also after sleeping on it a bit. bpf global
variable will also break if a bpf_prog.o has more than one SEC(".struct_ops").
For tracing program, the bpf cookie seems to be an existing mechanism that can
have any value (?). Thus, user space is free to store the map->id in it also. It
can also choose to store the map->id in a bpf global variable if it has other
uses for the bpf cookie. I think both should work similarly.
