On 10/15/24 6:04 PM, Jason Xing wrote:
To be honest, I considered how to disable the static key. Like you
said, I failed to find a good chance that I can accurately disable it.
It at least needs to be disabled whenever that bpf prog got detached.
quoted
The bpf prog may be detached also. (IF) it ends up staying with the
cgroup/sockops interface, it should depend on the existing static key in
cgroup_bpf_enabled(CGROUP_SOCK_OPS) instead of adding another one.
Are you suggesting that we need to remove the current static key? In
the previous thread, the reason why Willem came up with this idea is,
I think, to avoid affect the non-bpf timestamping feature.
Take a look at cgroup_bpf_enabled(CGROUP_SOCK_OPS). There is a static key. I am
saying to use that existing key. afaict, the newly added bpf_tstamp_control key
is mainly an optimization. Yes, cgroup_bpf_enabled(CGROUP_SOCK_OPS) is less
granular but it has the needed accounting to disable whenever the bpf prog got
detached, so better just reuse the cgroup_bpf_enabled(CGROUP_SOCK_OPS).