From: Stanislav Fomichev <stfomichev@gmail.com>
To: Zijian Zhang <zijianzhang@bytedance.com>
Cc: bpf@vger.kernel.org, borisp@nvidia.com, john.fastabend@gmail.com,
kuba@kernel.org, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, horms@kernel.org, daniel@iogearbox.net,
ast@kernel.org, cong.wang@bytedance.com
Subject: Re: [PATCH bpf] bpf: Add sk_is_inet check in tls_sw_has_ctx_tx/rx
Date: Wed, 30 Oct 2024 08:38:13 -0700 [thread overview]
Message-ID: <ZyJS5UCJu1YlsrJr@mini-arch> (raw)
In-Reply-To: <08853817-921b-4595-a7d5-67007bf21500@bytedance.com>
On 10/29, Zijian Zhang wrote:
>
> On 10/29/24 5:22 PM, Stanislav Fomichev wrote:
> > On 10/29, Zijian Zhang wrote:
> > >
> > >
> > > On 10/29/24 4:07 PM, Stanislav Fomichev wrote:
> > > > On 10/29, zijianzhang@bytedance.com wrote:
> ...
> > > > > diff --git a/include/net/tls.h b/include/net/tls.h
> > > > > index 3a33924db2bc..a65939c7ad61 100644
> > > > > --- a/include/net/tls.h
> > > > > +++ b/include/net/tls.h
> > > > > @@ -390,8 +390,12 @@ tls_offload_ctx_tx(const struct tls_context *tls_ctx)
> > > > > static inline bool tls_sw_has_ctx_tx(const struct sock *sk)
> > > > > {
> > > > > - struct tls_context *ctx = tls_get_ctx(sk);
> > > > > + struct tls_context *ctx;
> > > > > +
> > > > > + if (!sk_is_inet(sk))
> > > > > + return false;
> > > > > + ctx = tls_get_ctx(sk);
> > > > > if (!ctx)
> > > > > return false;
> > > > > return !!tls_sw_ctx_tx(ctx);
> > > > > @@ -399,8 +403,12 @@ static inline bool tls_sw_has_ctx_tx(const struct sock *sk)
> > > > > static inline bool tls_sw_has_ctx_rx(const struct sock *sk)
> > > > > {
> > > > > - struct tls_context *ctx = tls_get_ctx(sk);
> > > > > + struct tls_context *ctx;
> > > > > +
> > > > > + if (!sk_is_inet(sk))
> > > > > + return false;
> > > > > + ctx = tls_get_ctx(sk);
> > > > > if (!ctx)
> > > > > return false;
> > > > > return !!tls_sw_ctx_rx(ctx);
> > > >
> > > > This seems like a strange place to fix it. Why does tls_get_ctx return
> > > > invalid pointer for non-tls/ulp sockets? Shouldn't it be NULL?
> > > > Is sockmap even supposed to work with vsock?
> > >
> > > Here is my understanding, please correct me if I am wrong :)
> > > ```
> > > static inline struct tls_context *tls_get_ctx(const struct sock *sk)
> > > {
> > > const struct inet_connection_sock *icsk = inet_csk(sk);
> > > return (__force void *)icsk->icsk_ulp_data;
> > > }
> > > ```
> > > tls_get_ctx assumes the socket passed is icsk_socket. However, unix
> > > and vsock do not have inet_connection_sock, they have unix_sock and
> > > vsock_sock. The offset of icsk_ulp_data are meaningless for them, and
> > > they might point to some other values which might not be NULL.
> > >
> > > Afaik, sockmap started to support vsock in 634f1a7110b4 ("vsock: support
> > > sockmap"), and support unix in 94531cfcbe79 ("af_unix: Add
> > > unix_stream_proto for sockmap").
> > >
> > > If the above is correct, I find that using inet_test_bit(IS_ICSK, sk)
> > > instead of sk_is_inet will be more accurate.
> >
> > Thanks for the context, makes sense. And consolidating this sk_is_inet
> > check inside tls_get_ctx is worse because it gets called outside of
> > sockmap?
>
> Yes, tls_get_ctx is invoked in multiple locations, and I want to only
> fix sockmap related calls.
Sounds convincing. Unless John/Jakub have better suggestions:
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
next prev parent reply other threads:[~2024-10-30 15:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-29 20:28 [PATCH bpf] bpf: Add sk_is_inet check in tls_sw_has_ctx_tx/rx zijianzhang
2024-10-29 23:07 ` Stanislav Fomichev
2024-10-29 23:37 ` Zijian Zhang
2024-10-30 0:22 ` Stanislav Fomichev
2024-10-30 0:55 ` Zijian Zhang
2024-10-30 15:38 ` Stanislav Fomichev [this message]
2024-10-30 16:37 ` Zijian Zhang
2024-10-31 16:39 ` Stanislav Fomichev
2024-10-31 17:54 ` Zijian Zhang
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=ZyJS5UCJu1YlsrJr@mini-arch \
--to=stfomichev@gmail.com \
--cc=ast@kernel.org \
--cc=borisp@nvidia.com \
--cc=bpf@vger.kernel.org \
--cc=cong.wang@bytedance.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=pabeni@redhat.com \
--cc=zijianzhang@bytedance.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.