Jason Xing wrote: > BPF program calculates a couple of latency deltas between each tx > timestamping callbacks. It can be used in the real world to diagnose > the kernel behaviour in the tx path. > > Check the safety issues by accessing a few bpf calls in > bpf_test_access_bpf_calls() which are implemented in the patch 3 and 4. > > Check if the bpf timestamping can co-exist with socket timestamping. > > There remains a few realistic things[1][2] to highlight: > 1. in general a packet may pass through multiple qdiscs. For instance > with bonding or tunnel virtual devices in the egress path. > 2. packets may be resent, in which case an ACK might precede a repeat > SCHED and SND. > 3. erroneous or malicious peers may also just never send an ACK. > > [1]: https://lore.kernel.org/all/67a389af981b0_14e0832949d@xxxxxxxxxxxxxxxxxxxxxx.notmuch/ > [2]: https://lore.kernel.org/all/c329a0c1-239b-4ca1-91f2-cb30b8dd2f6a@xxxxxxxxx/ > > Signed-off-by: Jason Xing <kerneljasonxing@xxxxxxxxx> > +/* In the timestamping callbacks, we're not allowed to call the following > + * BPF CALLs for the safety concern. Return false if expected. > + */ > +static bool bpf_test_access_bpf_calls(struct bpf_sock_ops *skops, > + const struct sock *sk) Is this parameter aligned with the one on the previous line? This line was changed in the latest revision. Still looks off to me. But that may just be how the diff is presented in my vi. > +SEC("fentry/tcp_sendmsg_locked") > +int BPF_PROG(trace_tcp_sendmsg_locked, struct sock *sk, struct msghdr *msg, > + size_t size) Same
