From: Jakub Sitnicki <jakub@cloudflare.com>
To: John Fastabend <john.fastabend@gmail.com>
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, ast@kernel.org,
daniel@iogearbox.net
Subject: Re: [bpf PATCH 3/9] bpf: sockmap/tls, push write_space updates through ulp updates
Date: Thu, 09 Jan 2020 11:33:31 +0100 [thread overview]
Message-ID: <87tv54syv8.fsf@cloudflare.com> (raw)
In-Reply-To: <157851808101.1732.11616068811837364406.stgit@ubuntu3-kvm2>
On Wed, Jan 08, 2020 at 10:14 PM CET, John Fastabend wrote:
> When sockmap sock with TLS enabled is removed we cleanup bpf/psock state
> and call tcp_update_ulp() to push updates to TLS ULP on top. However, we
> don't push the write_space callback up and instead simply overwrite the
> op with the psock stored previous op. This may or may not be correct so
> to ensure we don't overwrite the TLS write space hook pass this field to
> the ULP and have it fixup the ctx.
>
> This completes a previous fix that pushed the ops through to the ULP
> but at the time missed doing this for write_space, presumably because
> write_space TLS hook was added around the same time.
>
> Fixes: 95fa145479fbc ("bpf: sockmap/tls, close can race with map free")
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
> ---
> include/linux/skmsg.h | 12 ++++++++----
> include/net/tcp.h | 6 ++++--
> net/ipv4/tcp_ulp.c | 6 ++++--
> net/tls/tls_main.c | 10 +++++++---
> 4 files changed, 23 insertions(+), 11 deletions(-)
>
> diff --git a/include/linux/skmsg.h b/include/linux/skmsg.h
> index b6afe01f8592..14d61bba0b79 100644
> --- a/include/linux/skmsg.h
> +++ b/include/linux/skmsg.h
> @@ -359,17 +359,21 @@ static inline void sk_psock_restore_proto(struct sock *sk,
> struct sk_psock *psock)
> {
> sk->sk_prot->unhash = psock->saved_unhash;
> - sk->sk_write_space = psock->saved_write_space;
>
> if (psock->sk_proto) {
> struct inet_connection_sock *icsk = inet_csk(sk);
> bool has_ulp = !!icsk->icsk_ulp_data;
>
> - if (has_ulp)
> - tcp_update_ulp(sk, psock->sk_proto);
> - else
> + if (has_ulp) {
> + tcp_update_ulp(sk, psock->sk_proto,
> + psock->saved_write_space);
> + } else {
> sk->sk_prot = psock->sk_proto;
> + sk->sk_write_space = psock->saved_write_space;
> + }
I'm wondering if we need the above fallback branch for no-ULP case?
tcp_update_ulp repeats the ULP check and has the same fallback. Perhaps
it can be reduced to:
if (psock->sk_proto) {
tcp_update_ulp(sk, psock->sk_proto, psock->saved_write_space);
psock->sk_proto = NULL;
} else {
sk->sk_write_space = psock->saved_write_space;
}
Then there's the question if it's okay to leave psock->sk_proto set and
potentially restore it more than once? Reading tls_update, the only user
ULP 'update' callback, it looks fine.
Can sk_psock_restore_proto be as simple as:
static inline void sk_psock_restore_proto(struct sock *sk,
struct sk_psock *psock)
{
tcp_update_ulp(sk, psock->sk_proto, psock->saved_write_space);
}
... or am I missing something?
Asking becuase I have a patch [0] like this in the queue and haven't
seen issues with it during testing.
-jkbs
[0] https://github.com/jsitnicki/linux/commit/2d2152593c8e6c5f38548796501a81a6ba20b6dc
> psock->sk_proto = NULL;
> + } else {
> + sk->sk_write_space = psock->saved_write_space;
> }
> }
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index e460ea7f767b..e6f48384dc71 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -2147,7 +2147,8 @@ struct tcp_ulp_ops {
> /* initialize ulp */
> int (*init)(struct sock *sk);
> /* update ulp */
> - void (*update)(struct sock *sk, struct proto *p);
> + void (*update)(struct sock *sk, struct proto *p,
> + void (*write_space)(struct sock *sk));
> /* cleanup ulp */
> void (*release)(struct sock *sk);
> /* diagnostic */
> @@ -2162,7 +2163,8 @@ void tcp_unregister_ulp(struct tcp_ulp_ops *type);
> int tcp_set_ulp(struct sock *sk, const char *name);
> void tcp_get_available_ulp(char *buf, size_t len);
> void tcp_cleanup_ulp(struct sock *sk);
> -void tcp_update_ulp(struct sock *sk, struct proto *p);
> +void tcp_update_ulp(struct sock *sk, struct proto *p,
> + void (*write_space)(struct sock *sk));
>
> #define MODULE_ALIAS_TCP_ULP(name) \
> __MODULE_INFO(alias, alias_userspace, name); \
> diff --git a/net/ipv4/tcp_ulp.c b/net/ipv4/tcp_ulp.c
> index 12ab5db2b71c..38d3ad141161 100644
> --- a/net/ipv4/tcp_ulp.c
> +++ b/net/ipv4/tcp_ulp.c
> @@ -99,17 +99,19 @@ void tcp_get_available_ulp(char *buf, size_t maxlen)
> rcu_read_unlock();
> }
>
> -void tcp_update_ulp(struct sock *sk, struct proto *proto)
> +void tcp_update_ulp(struct sock *sk, struct proto *proto,
> + void (*write_space)(struct sock *sk))
> {
> struct inet_connection_sock *icsk = inet_csk(sk);
>
> if (!icsk->icsk_ulp_ops) {
> + sk->sk_write_space = write_space;
> sk->sk_prot = proto;
> return;
> }
>
> if (icsk->icsk_ulp_ops->update)
> - icsk->icsk_ulp_ops->update(sk, proto);
> + icsk->icsk_ulp_ops->update(sk, proto, write_space);
> }
>
> void tcp_cleanup_ulp(struct sock *sk)
> diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
> index dac24c7aa7d4..94774c0e5ff3 100644
> --- a/net/tls/tls_main.c
> +++ b/net/tls/tls_main.c
> @@ -732,15 +732,19 @@ static int tls_init(struct sock *sk)
> return rc;
> }
>
> -static void tls_update(struct sock *sk, struct proto *p)
> +static void tls_update(struct sock *sk, struct proto *p,
> + void (*write_space)(struct sock *sk))
> {
> struct tls_context *ctx;
>
> ctx = tls_get_ctx(sk);
> - if (likely(ctx))
> + if (likely(ctx)) {
> + ctx->sk_write_space = write_space;
> ctx->sk_proto = p;
> - else
> + } else {
> sk->sk_prot = p;
> + sk->sk_write_space = write_space;
> + }
> }
>
> static int tls_get_info(const struct sock *sk, struct sk_buff *skb)
next prev parent reply other threads:[~2020-01-09 10:33 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-08 21:13 [bpf PATCH 0/9] Fixes for sockmap/tls from more complex BPF progs John Fastabend
2020-01-08 21:14 ` [bpf PATCH 1/9] bpf: sockmap/tls, during free we may call tcp_bpf_unhash() in loop John Fastabend
2020-01-09 1:34 ` Song Liu
2020-01-08 21:14 ` [bpf PATCH 2/9] bpf: sockmap, ensure sock lock held during tear down John Fastabend
2020-01-09 17:10 ` Song Liu
2020-01-08 21:14 ` [bpf PATCH 3/9] bpf: sockmap/tls, push write_space updates through ulp updates John Fastabend
2020-01-09 10:33 ` Jakub Sitnicki [this message]
2020-01-09 21:22 ` John Fastabend
2020-01-10 13:40 ` Jakub Sitnicki
2020-01-08 21:14 ` [bpf PATCH 4/9] bpf: sockmap, skmsg helper overestimates push, pull, and pop bounds John Fastabend
2020-01-09 18:37 ` Song Liu
2020-01-08 21:15 ` [bpf PATCH 5/9] bpf: sockmap/tls, msg_push_data may leave end mark in place John Fastabend
2020-01-09 18:51 ` Song Liu
2020-01-08 21:15 ` [bpf PATCH 6/9] bpf: sockmap/tls, tls_sw can create a plaintext buf > encrypt buf John Fastabend
2020-01-09 23:04 ` Jonathan Lemon
2020-01-08 21:15 ` [bpf PATCH 7/9] bpf: sockmap/tls, skmsg can have wrapped skmsg that needs extra chaining John Fastabend
2020-01-09 23:13 ` Jonathan Lemon
2020-01-08 21:16 ` [bpf PATCH 8/9] bpf: sockmap/tls, tls_push_record can not handle zero length skmsg John Fastabend
2020-01-09 20:08 ` Song Liu
2020-01-09 21:25 ` John Fastabend
2020-01-10 23:20 ` John Fastabend
2020-01-08 21:16 ` [bpf PATCH 9/9] bpf: sockmap/tls, fix pop data with SK_DROP return code John Fastabend
2020-01-09 23:28 ` Jonathan Lemon
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=87tv54syv8.fsf@cloudflare.com \
--to=jakub@cloudflare.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=john.fastabend@gmail.com \
--cc=netdev@vger.kernel.org \
/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.