On 3/17/23 10:23, Daniel Borkmann wrote:
On 3/17/23 6:18 PM, Martin KaFai Lau wrote:
On 3/17/23 8:23 AM, Daniel Borkmann wrote:
From the function itself what is not clear whether
callers that replace an existing one should do the synchronize_rcu()
themselves or if this should
be part of tcp_update_congestion_control?
bpf_struct_ops_map_free (in patch 1) also does synchronize_rcu() for
another reason (bpf_setsockopt), so the caller (bpf_struct_ops) is
doing it. From looking at tcp_unregister_congestion_control(), make
sense that it is more correct to have another synchronize_rcu() also
in tcp_update_congestion_control in case there will be other non
bpf_struct_ops caller doing update in the future.
Agree, I was looking at 'bpf: Update the struct_ops of a bpf_link', and
essentially as-is
it was implicit via map free. +1, tcp_update_congestion_control() would
be more obvious and
better for other/non-BPF users.
It makes sense to me.
I will refactor functions as well.
Thanks,
Daniel
