[PATCH 0/2] nvme,tls: minimal handling for TLS records

[PATCH 0/2] nvme,tls: minimal handling for TLS records

[Hannes Reinecke]

Hi all,

TLS 1.3 can send additional TLS records while the connection is established,
and typically one would evaluate these records with passing in a control message
buffer for recvmsg(). But nvme-tcp is using the read_sock() interface which
does not allow for handling of control messages.
So as the lazy way out I opted for resetting the queue on any non-data TLS records
as this would be the default action anyway for most non-data TLS records.
But turns out that this does not work as planned, as the TLS records are evaluated
(and errors generated) before ->read_sock() is called, so nvme-tcp would receive
the error but not start error recovery.

This patchset is the minimal fix to handle it, start error recovery when a non-data
TLS record is received and also return a distinct error code from tls to indicate
the situation.

The 'real' fix will of course involve actually reading the control message and take
action based on the type, but that is a rather involved operation which will be addressed
later. So for now this simple fix should be sufficient.

Martin Belanger (2):
  nvme-tcp: start error recovery when read_sock fails
  tls: return a distinct error for control records from read_sock

 drivers/nvme/host/tcp.c | 18 +++++++++++++++++-
 net/tls/tls_sw.c        |  4 ++--
 2 files changed, 19 insertions(+), 3 deletions(-)

-- 
2.51.0

[PATCH 1/2] nvme-tcp: start error recovery when read_sock fails

[Hannes Reinecke]

From: Martin Belanger <martin.belanger@dell.com>

nvme_tcp_recv_skb() disables the queue and starts error recovery on any
errors. But if the transport encounters an error before ->read_sock()
is called (and hence before nvme_tcp_recv_skb() is called) no further
action is taken. This causes nvme_tcp_io_work() to stall until a command
times out.

This patch checks for any error returned from ->read_sock(), and starts
error recovery when the queue is still enabled (ie if nvme_tcp_recv_skb()
has not detected the error).

Signed-off-by: Martin Belanger <martin.belanger@dell.com>
Signed-off-by: Hannes Reinecke <hare@kernel.org>
---
 drivers/nvme/host/tcp.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
index 7eec983c0ead..2f1ae3968678 100644
--- a/drivers/nvme/host/tcp.c
+++ b/drivers/nvme/host/tcp.c
@@ -1422,7 +1422,23 @@ static int nvme_tcp_try_recv(struct nvme_tcp_queue *queue)
 	queue->nr_cqe = 0;
 	consumed = sock->ops->read_sock(sk, &rd_desc, nvme_tcp_recv_skb);
 	release_sock(sk);
-	return consumed == -EAGAIN ? 0 : consumed;
+	if (consumed == -EAGAIN)
+		return 0;
+
+	/*
+	 * read_sock() might encounter an error before calling
+	 * nvme_tcp_recv_skb(), so we need to check if we need
+	 * to start error recovery here.
+	 */
+	if (unlikely(consumed < 0 && queue->rd_enabled)) {
+		dev_err(queue->ctrl->ctrl.device,
+			"queue %d: receive failed: %d\n",
+			nvme_tcp_queue_id(queue), consumed);
+		queue->rd_enabled = false;
+		nvme_tcp_error_recovery(&queue->ctrl->ctrl);
+	}
+
+	return consumed;
 }
 
 static void nvme_tcp_io_work(struct work_struct *w)
-- 
2.51.0

[PATCH 2/2] tls: return a distinct error for control records from read_sock

[Hannes Reinecke]

From: Martin Belanger <martin.belanger@dell.com>

tls_sw_read_sock() leaves a non-data record on the receive list and
returns -EINVAL. The same function returns -EINVAL when an sk_psock is
attached, and an actor may return it for other reasons, so callers
cannot determine whether a control record is waiting.

Return -EPROTO instead. The record can then be read with recvmsg()
and a control buffer, which reports its type.

Signed-off-by: Martin Belanger <martin.belanger@dell.com>
Signed-off-by: Hannes Reinecke <hare@kernel.org>
---
 net/tls/tls_sw.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index d1ad31986cf2..7ac606900ff8 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -2044,7 +2044,7 @@ ssize_t tls_sw_splice_read(struct socket *sock,  loff_t *ppos,
 
 	/* splice does not support reading control messages */
 	if (tlm->control != TLS_RECORD_TYPE_DATA) {
-		err = -EINVAL;
+		err = -EPROTO;
 		goto splice_requeue;
 	}
 
@@ -2132,7 +2132,7 @@ int tls_sw_read_sock(struct sock *sk, read_descriptor_t *desc,
 
 		/* read_sock does not support reading control messages */
 		if (tlm->control != TLS_RECORD_TYPE_DATA) {
-			err = -EINVAL;
+			err = -EPROTO;
 			goto read_sock_requeue;
 		}
 
-- 
2.51.0

Re: [PATCH 2/2] tls: return a distinct error for control records from read_sock

[Jakub Kicinski]

On Tue, 22 Sep 2026 15:37:08 +0200 Hannes Reinecke wrote:
> tls_sw_read_sock() leaves a non-data record on the receive list and
> returns -EINVAL. The same function returns -EINVAL when an sk_psock is
> attached, and an actor may return it for other reasons, so callers
> cannot determine whether a control record is waiting.
> 
> Return -EPROTO instead. The record can then be read with recvmsg()
> and a control buffer, which reports its type.

Please run the selftests.
-- 
pw-bot: cr