[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL+tcoAN5EZbAzHDsWLpnzZ0sE5--_3qD5SQfVZf-OSZTw_gGw@mail.gmail.com>
Date: Sun, 16 Feb 2025 00:17:14 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, dsahern@...nel.org, willemb@...gle.com, ast@...nel.org,
daniel@...earbox.net, andrii@...nel.org, martin.lau@...ux.dev,
eddyz87@...il.com, song@...nel.org, yonghong.song@...ux.dev,
john.fastabend@...il.com, kpsingh@...nel.org, sdf@...ichev.me,
haoluo@...gle.com, jolsa@...nel.org, horms@...nel.org, bpf@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH bpf-next v11 12/12] selftests/bpf: add simple bpf tests in
the tx path for timestamping feature
On Sat, Feb 15, 2025 at 11:15 PM Willem de Bruijn
<willemdebruijn.kernel@...il.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@...il.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.
Thanks,
Jason
Powered by blists - more mailing lists