On Sat, Feb 15, 2025 at 11:15 PM Willem de Bruijn <willemdebruijn.kernel@xxxxxxxxx> wrote: > > 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 Weird. I cannot see the problem from my machine. The CI didn't warn me on this alignment either. Probably your vi went wrong? I'm not sure. Thanks, Jason
