[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CALye=_8_zGg3vnKtk4qrTN2RN7Y4yfEqD1G3Sf=AJSCwBcJkbA@mail.gmail.com>
Date: Fri, 20 Jun 2025 17:44:48 +0200
From: Vincent Whitchurch <vincent.whitchurch@...adoghq.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Vincent Whitchurch via B4 Relay <devnull+vincent.whitchurch.datadoghq.com@...nel.org>,
John Fastabend <john.fastabend@...il.com>, Jakub Sitnicki <jakub@...udflare.com>,
Kuniyuki Iwashima <kuniyu@...zon.com>, netdev@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: [PATCH bpf-next v2 1/5] net: Add splice_read to prot
On Wed, Jun 11, 2025 at 10:57 AM Vincent Whitchurch
<vincent.whitchurch@...adoghq.com> wrote:
> On Mon, Jun 9, 2025 at 9:21 PM Jakub Kicinski <kuba@...nel.org> wrote:
> > Can we not override proto_ops in tcp_bpf for some specific reason?
> > TLS does that, IIUC.
>
> I see that TLS writes to sk->sk_socket->ops to override the proto_ops.
> I added some prints to tcp_bpf_update_proto() but there I see that
> sk->sk_socket is NULL in some code paths, like the one below.
To expand on this: TLS is able to override the sk->sk_socket->ops
since it can only be installed on the socket via setsockopt(2).
tcp_bpf on the other hand allows being installed on passively
established sockets before they have a sk->sk_socket assigned via
accept(2). So, AFAICS, we can't use the same override mechanism as
TLS.
Powered by blists - more mailing lists