summaryrefslogtreecommitdiffstats
path: root/net
diff options
context:
space:
mode:
authorBenjamin Coddington <bcodding@redhat.com>2025-01-04 16:29:45 +0100
committerJakub Kicinski <kuba@kernel.org>2025-01-08 02:00:19 +0100
commitb341ca51d2679829d26a3f6a4aa9aee9abd94f92 (patch)
treec75e389676b1bc2856fc996a078a3be5904687a1 /net
parenteth: fbnic: Revert "eth: fbnic: Add hardware monitoring support via HWMON int... (diff)
downloadlinux-b341ca51d2679829d26a3f6a4aa9aee9abd94f92.tar.xz
linux-b341ca51d2679829d26a3f6a4aa9aee9abd94f92.zip
tls: Fix tls_sw_sendmsg error handling
We've noticed that NFS can hang when using RPC over TLS on an unstable connection, and investigation shows that the RPC layer is stuck in a tight loop attempting to transmit, but forever getting -EBADMSG back from the underlying network. The loop begins when tcp_sendmsg_locked() returns -EPIPE to tls_tx_records(), but that error is converted to -EBADMSG when calling the socket's error reporting handler. Instead of converting errors from tcp_sendmsg_locked(), let's pass them along in this path. The RPC layer handles -EPIPE by reconnecting the transport, which prevents the endless attempts to transmit on a broken connection. Signed-off-by: Benjamin Coddington <bcodding@redhat.com> Fixes: a42055e8d2c3 ("net/tls: Add support for async encryption of records for performance") Link: https://patch.msgid.link/9594185559881679d81f071b181a10eb07cd079f.1736004079.git.bcodding@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'net')
-rw-r--r--net/tls/tls_sw.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index bbf26cc4f6ee..7bcc9b4408a2 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -458,7 +458,7 @@ int tls_tx_records(struct sock *sk, int flags)
tx_err:
if (rc < 0 && rc != -EAGAIN)
- tls_err_abort(sk, -EBADMSG);
+ tls_err_abort(sk, rc);
return rc;
}