On Sat, Jan 18, 2025 at 9:42 AM Martin KaFai Lau <martin.lau@xxxxxxxxx> wrote: > > On 1/15/25 5:12 PM, Jason Xing wrote: > >>> Also, I need to set allow_direct_access to one as long as there is > >>> "sock_ops.is_fullsock = 1;" in the existing callbacks. > >> Only set allow_direct_access when the sk is fullsock in the "existing" sockops > >> callback. > > Only "existing"? Then how can the bpf program access those members of > > the tcp socket structure in the current/new timestamping callbacks? > > There is at least one sk write: > > case offsetof(struct bpf_sock_ops, sk_txhash): > SOCK_OPS_GET_OR_SET_FIELD(sk_txhash, sk_txhash, > struct sock, type); > > afaict, the kernel always writes sk->sk_txhash with the sk lock held. The new > timestamping callbacks cannot write because it does not hold the lock. Surely, I will handle the sk_txhash case as you suggested :) > Otherwise, it needs another flag in bpf_sock_ops_kern to say read only or not. > imo, it is too complicated to be worth it. > > It is fine for the new timestamping callbacks not able to access the tcp_sock > fields through the bpf_sock_ops. We are not losing anything. The accessible Oh, that was my concern. > tcp_sock fields through the bpf_sock_ops is limited and the bpf_sock_ops api is > pretty much frozen. The bpf prog should use the bpf_core_cast(skops->sk, struct > tcp_sock). The future UDP timestamping support will likely need to use the > bpf_core_cast anyway because we are not extending "struct bpf_sock_ops" for the > udp_sock specific fields. Thanks! Now I learned an interesting usage about bpf! Thanks, Jason
