lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <67b0d66ec8d50_3818932941e@willemb.c.googlers.com.notmuch>
Date: Sat, 15 Feb 2025 13:01:18 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Jason Xing <kerneljasonxing@...il.com>, 
 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

Jason Xing wrote:
> 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.

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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ