* [PATCH net v2] net/tls: Inform user space about send buffer availability
@ 2019-03-12 8:22 Vakul Garg
2019-03-13 21:17 ` David Miller
0 siblings, 1 reply; 2+ messages in thread
From: Vakul Garg @ 2019-03-12 8:22 UTC (permalink / raw)
To: netdev; +Cc: borisp, aviadye, davejwatson, davem, doronrk, Vakul Garg
A previous fix ("tls: Fix write space handling") assumed that
user space application gets informed about the socket send buffer
availability when tls_push_sg() gets called. Inside tls_push_sg(), in
case do_tcp_sendpages() returns 0, the function returns without calling
ctx->sk_write_space. Further, the new function tls_sw_write_space()
did not invoke ctx->sk_write_space. This leads to situation that user
space application encounters a lockup always waiting for socket send
buffer to become available.
Rather than call ctx->sk_write_space from tls_push_sg(), it should be
called from tls_write_space. So whenever tcp stack invokes
sk->sk_write_space after freeing socket send buffer, we always declare
the same to user space by the way of invoking ctx->sk_write_space.
Fixes: 7463d3a2db0ef ("tls: Fix write space handling")
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
Reviewed-by: Boris Pismenny <borisp@mellanox.com>
---
net/tls/tls_device.c | 3 ---
net/tls/tls_main.c | 3 ++-
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
index 4a1da837a733..135a7ee9db03 100644
--- a/net/tls/tls_device.c
+++ b/net/tls/tls_device.c
@@ -558,9 +558,6 @@ void tls_device_write_space(struct sock *sk, struct tls_context *ctx)
MSG_DONTWAIT | MSG_NOSIGNAL);
sk->sk_allocation = sk_allocation;
}
-
- if (!rc)
- ctx->sk_write_space(sk);
}
void handle_device_resync(struct sock *sk, u32 seq, u64 rcd_sn)
diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
index 17e8667917aa..df921a2904b9 100644
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
@@ -146,7 +146,6 @@ int tls_push_sg(struct sock *sk,
}
ctx->in_tcp_sendpages = false;
- ctx->sk_write_space(sk);
return 0;
}
@@ -228,6 +227,8 @@ static void tls_write_space(struct sock *sk)
else
#endif
tls_sw_write_space(sk, ctx);
+
+ ctx->sk_write_space(sk);
}
static void tls_ctx_free(struct tls_context *ctx)
--
2.13.6
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH net v2] net/tls: Inform user space about send buffer availability
2019-03-12 8:22 [PATCH net v2] net/tls: Inform user space about send buffer availability Vakul Garg
@ 2019-03-13 21:17 ` David Miller
0 siblings, 0 replies; 2+ messages in thread
From: David Miller @ 2019-03-13 21:17 UTC (permalink / raw)
To: vakul.garg; +Cc: netdev, borisp, aviadye, davejwatson, doronrk
From: Vakul Garg <vakul.garg@nxp.com>
Date: Tue, 12 Mar 2019 08:22:57 +0000
> A previous fix ("tls: Fix write space handling") assumed that
> user space application gets informed about the socket send buffer
> availability when tls_push_sg() gets called. Inside tls_push_sg(), in
> case do_tcp_sendpages() returns 0, the function returns without calling
> ctx->sk_write_space. Further, the new function tls_sw_write_space()
> did not invoke ctx->sk_write_space. This leads to situation that user
> space application encounters a lockup always waiting for socket send
> buffer to become available.
>
> Rather than call ctx->sk_write_space from tls_push_sg(), it should be
> called from tls_write_space. So whenever tcp stack invokes
> sk->sk_write_space after freeing socket send buffer, we always declare
> the same to user space by the way of invoking ctx->sk_write_space.
>
> Fixes: 7463d3a2db0ef ("tls: Fix write space handling")
> Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
> Reviewed-by: Boris Pismenny <borisp@mellanox.com>
Applied, thanks Vakul.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2019-03-13 21:17 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-12 8:22 [PATCH net v2] net/tls: Inform user space about send buffer availability Vakul Garg
2019-03-13 21:17 ` David Miller
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).