Re: [PATCH bpf-next v11 12/12] selftests/bpf: add simple bpf tests in the tx path for timestamping feature

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

Jason Xing wrote:
> On Sat, Feb 15, 2025 at 11:15 PM Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> 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@willemb.c.googlers.com.notmuch/
> > > [2]: https://lore.kernel.org/all/c329a0c1-239b-4ca1-91f2-cb30b8dd2f6a@linux.dev/
> > >
> > > Signed-off-by: Jason Xing <kerneljasonxing@gmail.com>
> >
> > > +/* 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.

If you double checked, I trust that it's just representation in my
client.