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.
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).
