netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Jason Xing <kerneljasonxing@gmail.com>,
	 Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: davem@davemloft.net,  edumazet@google.com,  kuba@kernel.org,
	 pabeni@redhat.com,  dsahern@kernel.org,  willemb@google.com,
	 ast@kernel.org,  daniel@iogearbox.net,  andrii@kernel.org,
	 martin.lau@linux.dev,  eddyz87@gmail.com,  song@kernel.org,
	 yonghong.song@linux.dev,  john.fastabend@gmail.com,
	 kpsingh@kernel.org,  sdf@fomichev.me,  haoluo@google.com,
	 jolsa@kernel.org,  bpf@vger.kernel.org,  netdev@vger.kernel.org,
	 Jason Xing <kernelxing@tencent.com>
Subject: Re: [PATCH net-next 6/9] net-timestamp: add tx OPT_ID_TCP support for bpf case
Date: Wed, 09 Oct 2024 09:19:41 -0400	[thread overview]
Message-ID: <670682ed93e9c_1cca3129431@willemb.c.googlers.com.notmuch> (raw)
In-Reply-To: <CAL+tcoA_HwCYG+_DtdRHNL-L07RYqQfxY+pmT2fUvs-N1HYV9g@mail.gmail.com>

Jason Xing wrote:
> On Wed, Oct 9, 2024 at 2:56 AM Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
> >
> > Jason Xing wrote:
> > > From: Jason Xing <kernelxing@tencent.com>
> > >
> > > We can set OPT_ID|OPT_ID_TCP before we initialize the last skb
> > > from each sendmsg. We only set the socket once like how we use
> > > setsockopt() with OPT_ID|OPT_ID_TCP flags.
> > >
> > > Signed-off-by: Jason Xing <kernelxing@tencent.com>
> > > ---
> > >  net/core/skbuff.c | 16 +++++++++++++---
> > >  net/ipv4/tcp.c    | 19 +++++++++++++++----
> > >  2 files changed, 28 insertions(+), 7 deletions(-)
> > >
> >
> > > @@ -491,10 +491,21 @@ static u32 bpf_tcp_tx_timestamp(struct sock *sk)
> > >       if (!(flags & SOF_TIMESTAMPING_TX_RECORD_MASK))
> > >               return 0;
> > >
> > > +     /* We require users to set both OPT_ID and OPT_ID_TCP flags
> > > +      * together here, or else the key might be inaccurate.
> > > +      */
> > > +     if (flags & SOF_TIMESTAMPING_OPT_ID &&
> > > +         flags & SOF_TIMESTAMPING_OPT_ID_TCP &&
> > > +         !(sk->sk_tsflags & (SOF_TIMESTAMPING_OPT_ID | SOF_TIMESTAMPING_OPT_ID_TCP))) {
> > > +             atomic_set(&sk->sk_tskey, (tcp_sk(sk)->write_seq - copied));
> > > +             sk->sk_tsflags |= (SOF_TIMESTAMPING_OPT_ID | SOF_TIMESTAMPING_OPT_ID_TCP);
> >
> > So user and BPF admin conflict on both sk_tsflags and sktskey?
> >
> > I think BPF resetting this key, or incrementing it, may break user
> > expectations.
> 
> Yes, when it comes to OPT_ID and OPT_ID_TCP, conflict could happen.
> The reason why I don't use it like BPF_SOCK_OPS_TS_SCHED_OPT_CB flags
> (which is set along with each last skb) is that OPT_ID logic is a
> little bit complex. If we want to avoid touching sk_tsflags field in
> struct sock, we have to re-implement a similiar logic as you've
> already done in these years.

One option may be to only allow BPF to use sk_tsflags and sk_tskey if
sk_tsflags is not set by the user, and to fail user access to these
fields later.

That enforces mutual exclusion between either user or admin
timestamping.

Of course, it may still break users if BPF is first, but the user
socket tries to enable it later. So an imperfect solution.

Ideally the two would use separate per socket state. I don't know
all the options the various BPF hooks may have for this.


  reply	other threads:[~2024-10-09 13:19 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-08  9:51 [PATCH net-next 0/9] net-timestamp: bpf extension to equip applications transparently Jason Xing
2024-10-08  9:51 ` [PATCH net-next 1/9] net-timestamp: add bpf infrastructure to allow exposing more information later Jason Xing
2024-10-08 18:45   ` Willem de Bruijn
2024-10-08 23:27     ` Jason Xing
2024-10-09 13:22       ` Willem de Bruijn
2024-10-09 13:57         ` Jason Xing
2024-10-09  0:58   ` Kuniyuki Iwashima
2024-10-09  8:11     ` Jason Xing
2024-10-08  9:51 ` [PATCH net-next 2/9] net-timestamp: introduce TS_SCHED_OPT_CB to generate dev xmit timestamp Jason Xing
2024-10-08  9:51 ` [PATCH net-next 3/9] net-timestamp: introduce TS_SW_OPT_CB to generate driver timestamp Jason Xing
2024-10-08 19:13   ` Vadim Fedorenko
2024-10-08 23:08     ` Jason Xing
2024-10-08  9:51 ` [PATCH net-next 4/9] net-timestamp: introduce TS_ACK_OPT_CB to generate tcp acked timestamp Jason Xing
2024-10-08  9:51 ` [PATCH net-next 5/9] net-timestamp: ready to turn on the button to generate tx timestamps Jason Xing
2024-10-08 18:53   ` Willem de Bruijn
2024-10-08 23:37     ` Jason Xing
2024-10-08 19:18   ` Vadim Fedorenko
2024-10-08 23:48     ` Jason Xing
2024-10-09  9:16       ` Vadim Fedorenko
2024-10-09 11:15         ` Jason Xing
2024-10-08  9:51 ` [PATCH net-next 6/9] net-timestamp: add tx OPT_ID_TCP support for bpf case Jason Xing
2024-10-08 18:56   ` Willem de Bruijn
2024-10-08 23:18     ` Jason Xing
2024-10-09 13:19       ` Willem de Bruijn [this message]
2024-10-09 13:52         ` Jason Xing
2024-10-08  9:51 ` [PATCH net-next 7/9] net-timestamp: open gate for bpf_setsockopt Jason Xing
2024-10-09  7:19   ` Martin KaFai Lau
2024-10-09  8:09     ` Jason Xing
2024-10-09 13:23       ` Willem de Bruijn
2024-10-09 13:48         ` Jason Xing
2024-10-08  9:51 ` [PATCH net-next 8/9] net-timestamp: add bpf framework for rx timestamps Jason Xing
2024-10-09  0:22   ` Jakub Kicinski
2024-10-09  0:30     ` Jason Xing
2024-10-09  2:33   ` kernel test robot
2024-10-09  4:17   ` kernel test robot
2024-10-09  5:09   ` kernel test robot
2024-10-08  9:51 ` [PATCH net-next 9/9] net-timestamp: add bpf support for rx software/hardware timestamp Jason Xing
2024-10-08 18:44 ` [PATCH net-next 0/9] net-timestamp: bpf extension to equip applications transparently Willem de Bruijn
2024-10-08 23:22   ` Jason Xing
2024-10-09  1:05     ` Jason Xing
2024-10-09  9:27       ` Vadim Fedorenko
2024-10-09 11:12         ` Jason Xing
2024-10-09 11:48           ` Jason Xing
2024-10-09 13:16             ` Vadim Fedorenko
2024-10-09 13:47               ` Jason Xing
2024-10-09 13:58                 ` Vadim Fedorenko
2024-10-09 14:35                   ` Jason Xing
2024-10-09 14:59                     ` Vadim Fedorenko
2024-10-09 15:20                       ` Jason Xing

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=670682ed93e9c_1cca3129431@willemb.c.googlers.com.notmuch \
    --to=willemdebruijn.kernel@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=eddyz87@gmail.com \
    --cc=edumazet@google.com \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kerneljasonxing@gmail.com \
    --cc=kernelxing@tencent.com \
    --cc=kpsingh@kernel.org \
    --cc=kuba@kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sdf@fomichev.me \
    --cc=song@kernel.org \
    --cc=willemb@google.com \
    --cc=yonghong.song@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).